+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+---- Forum: JSON-RPC (https://forum.kodi.tv/forumdisplay.php?fid=174)
+---- Thread: JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC (/showthread.php?tid=68263)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
- topfs2 - 2010-10-26
Therms Wrote:Are the current methods listed by Introspect the only methods that will make Dharma final?
Any chance an ExecBuiltIn will be making it in soon?
Nope, execbuiltin is one of those methods jsonrpc really don't want. its impossible to have a proper security clearence for it (except stating the clearance as admin)
- jitterjames - 2010-10-26
It looks like it will be necessary to use both JSON and the http api for a while in order to fill the gaps. Are there any obvious drawbacks to doing that?
It should be OK to use both right?
- Therms - 2010-10-26
topfs2 Wrote:Nope, execbuiltin is one of those methods jsonrpc really don't want. its impossible to have a proper security clearence for it (except stating the clearance as admin)
Understood.
With the HTTP API being deprecated, are there any sort of plans to implement something different, or will the execbuiltin method of the HTTP API be "undeprecated"?
- jitterjames - 2010-10-26
I get the impression that the http api stuff will be left in there for a while, just not updated. Is that correct?
- sWORDs - 2010-10-26
I've returned from vacation last weekend and am finishing up my EventServer Client (for Philips Pronto) so I can start on some XBMC EventServer and JSON client developer documentation right after that.
topfs2 Wrote:Also I am taking my masters in, amongst other things, designing applications for users and I am always trying to make applications as good as possible for all sorts of users. I would say that most of the xbmc community is really striving to make an application that is as simple as possible. So I'm actually abit offended.I know some comments might be offending and some people don't understand the amount of work put in already and the amount needed. I also know comments like that might damage the drive of the developer (I've dropped two projects because of things like this). And we probably don't say it often enought, but you're doing great work and 99% of the developers here really really appreciate all your work so I hope you won't be damaged by the few that don't.
jitterjames Wrote:It looks like it will be necessary to use both JSON and the http api for a while in order to fill the gaps. Are there any obvious drawbacks to doing that?
It should be OK to use both right?
I'm using EventServer and HTTPAPI to fill the gaps (eventserver is faster then HTTPAPI for the keypresses and actions on my remote because http auto closes the socket and with EventServer it's possible to keep a keypressed, also beta 1 and 2 didn't support http post) and will move functions to JSON one by one once they're available. No drawbacks accept a larger client codebase/load.
jitterjames Wrote:I get the impression that the http api stuff will be left in there for a while, just not updated. Is that correct?
While it could be different aslong as JSON isn't complete/almost bug free, topfs2 stated that it will be removed in Eden (v11).
- jitterjames - 2010-10-26
It seems like an odd thing to do, even if the the JSON is finished and everyone is happy with it, because there are a lot of apps that are using the http api.
Why pull the rug out from under them? (
by which I also mean me...)It would be nice if there were an overlap for a while, after JSON is finished, to give us a chance to cross over completely.
just my opinion...
- sWORDs - 2010-10-26
While I do agree that a version with both complete would be a nice transfer period, the time between now and Eden is pretty long, more then enough to switch to JSON, the few functions missing can be added really quick and you could build them while Eden is in alpha or beta. So even if the devs decide to go with the current planning it doesn't have to be problematic.
- topfs2 - 2010-10-27
Just want to point out that it is not decided if it will be dropped in Eden or not, depends much on how far along clients and jsonrpc in itself have come.
Also client creators will most likely need to update their app for eden with httpapi at any rate (new database and so on, madness of httpapi) so they might aswell update to something which will be alot more future proof
- Temar - 2010-10-30
Sorry if this has been asked before in this thread - I didn't read all the pages.
Is there a normal TCP socket I can send my RPC calls to, so I don't have to deal with the HTTP overhead? I would like to minimize the dependencies of my project and getting rid of libcurl would be nice.
- topfs2 - 2010-10-30
9090 raw tcp
- Temar - 2010-10-30
topfs2 Wrote:9090 raw tcp
Thanks.
- _Andy_ - 2010-10-30
Is it possible to querry the actresses/actors including hers/his picture?
In TV-Show mode in XBMC i have the possibility to show the cast of a show.
I want to do this in my GUI too.
- Temar - 2010-10-31
Are there any plans to implement a basic protocol on the raw JSON TCP socket, similar to i.e. the SMTP protocol? I was thinking about something like that:
Code:
telnet localhost 9090
220 Welcome to XBMC
{"jsonrpc" : "2.0", "method" : "InvalidMethod", "id" : "1"}
550 {
550 "error" : {
550 "code" : -32601,
550 "message" : "Method not found."
550 },
550 "id" : "1",
550 "jsonrpc" : "2.0"
550 }
220 ERROR
{"jsonrpc" : "2.0", "method" : "Player.GetActivePlayers", "id" : "1"}
250 {
250 "id" : "1",
250 "jsonrpc" : "2.0",
250 "result" : {
250 "audio" : false,
250 "picture" : false,
250 "video" : false
250 }
250 }
220 OKThe way it is now, working with the raw TCP socket is a bit tedious. You either have to parse the request while you are receiving data or you have to wait until no data is available anymore. However it is not guaranteed that the request is complete when there is no data anymore to read - it could just mean you didn't wait long enough. Also if you parse the response while receiving, a XBMC bug could send invalid data and your thread might block forever waiting for unfished data. Again you are back to a timeout - but what is the optimal timeout value?
If the responses would be encapsulated into a very simple protocol, it would be easier to determine the end of a response. I know I could use the HTTP protocol, but HTTP is a huge overhead. I'm just recommending a very simple protocol so the end of a command can be detected reliably. The way it is now, working with the raw TCP socket is very error prone.
Are there any plans in implementing such a protocol for the raw TCP socket? Would a patch be accepted?
- topfs2 - 2010-10-31
Temar Wrote:The way it is now, working with the raw TCP socket is a bit tedious. You either have to parse the request while you are receiving data or you have to wait until no data is available anymore. However it is not guaranteed that the request is complete when there is no data anymore to read - it could just mean you didn't wait long enough. Also if you parse the response while receiving, a XBMC bug could send invalid data and your thread might block forever waiting for unfished data. Again you are back to a timeout - but what is the optimal timeout value?
If the responses would be encapsulated into a very simple protocol, it would be easier to determine the end of a response. I know I could use the HTTP protocol, but HTTP is a huge overhead. I'm just recommending a very simple protocol so the end of a command can be detected reliably. The way it is now, working with the raw TCP socket is very error prone.
Are there any plans in implementing such a protocol for the raw TCP socket? Would a patch be accepted?
Thing is we are following the jsonrpc spec for the tcp port, so there exist many libraries that can handle it for you already.
Also there are many sequential json parser out there, which means you'll get the data as it comes in and don't need to guess when the object is over (and by guess you would just count { and } which is what we do in xbmc). Another very common way to deal with messaging like this is to have one thread sending and one receiving, you then push received messages (e.g. full json-objects) on a message queue monitor class (thread safe class). You can then easily get messages or send them from main thread if you want.
I think its also safe to assume that the data won't be bad,i.e. xbmc will send properly formated json objects. If we don't it would be extremely bad and not something that happens randomly so I don't consider that a problem. Second that could happen is socket could go down in the middle of a json object but then you would get pushed out of lock and errno would be set so should also be no problem.
All in all, I don't see the need for smtp type protocol. The reason they had it was that the needed to encapsulate or differentiate stuff, json objects are that already by default through the { }.
- Temar - 2010-10-31
topfs2 Wrote:Also there are many sequential json parser out there, which means you'll get the data as it comes in and don't need to guess when the object is over (and by guess you would just count { and } which is what we do in xbmc).
Yes, I'm also counting { and } atm for message detection.
Quote:I think its also safe to assume that the data won't be bad,i.e. xbmc will send properly formated json objects. If we don't it would be extremely bad and not something that happens randomly so I don't consider that a problem.
That is the point I'm worried about. A failing socket is not the problem, as it can be easily detected. My concern is more about invalid responses where i.e. a result string is not properly escaped and contains a {. But you are right, that scenario would probably not occur randomly and would be a serious bug.
Quote:All in all, I don't see the need for smtp type protocol. The reason they had it was that the needed to encapsulate or differentiate stuff, json objects are that already by default through the { }.
Well, was just a suggestion - I can live with counting brackets, too.
It's just that I don't trust protocols where you have to rely on a complex data format being sent correctly. Protocols which offer a simple and reliable way to detect the end of a message are just nicer to handle and less error prone.