+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Development (/forumdisplay.php?fid=93)
+---- Forum: JSON-RPC (/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 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289
- jitterjames - 2010-10-26 23:22
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 23:31
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 00:49
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 13:08
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 17:43
9090 raw tcp
- Temar - 2010-10-30 19:06
topfs2 Wrote:9090 raw tcp
Thanks.
- _Andy_ - 2010-10-30 21:24
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 16:09
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 17:56
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 18:44
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.