JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC - Printable Version +- 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
|
- jonib - 2010-10-10 barrygordon Wrote:I have seen several references to the document that describes the JSON methods that have been implemented to date. The one I have is dated feb 15 2010. Is that the latest one? If not could some one post a URL to the latest one? I have ssen instructions on how to get to it but all I ever end up with is a blank web page or a web page not foundThis seems to be the only (external to XBMC) documentation I know. jonib - barrygordon - 2010-10-10 Thank you jonib. Sometimes how fast a response comes back amazes me!! - xgamer99 - 2010-10-11 It would be wonderful if a path parameter could be added to <library>.ScanForContent, and perhaps add a <library>.CleanLibrary method that also takes a path. I created a request for the feature here with more details, and there's also a TRAC associated with it. Just posting it here to maybe get a little more exposure. The CleanLibrary method, while nice, isn't really a priority, however I would love the path parameter added to both AudioLibrary.ScanForContent and VideoLibrary.ScanForContent. From what I understand there was a patch posted in this very thread a few months ago that added this feature; however, the patch is no longer hosted and the poster hasn't logged on for months. ;_; - sWORDs - 2010-10-11 Questions already answered (found them out by testing). - Nick8888 - 2010-10-11 1. topfs2 Wrote:jsonrpc isn't really finialized for dharma but a stepping stone, until its final or atleast have enough features to deprecate http-api, http-api will remainworking fine for me with whats in the wiki - sWORDs - 2010-10-11 barrygordon Wrote:I assume if I use the raw port I would just send I've just tested with the raw socket (using putty raw socket to 9090). Drop the /jsonrpc part. The return isn't compacted: send: Code: {"jsonrpc":"2.0","method":"Player.GetActivePlayers","id":1} received: Code: { What is interesting are the announcements, this is what happens when I select a song using ordinairy controls: Code: { I've also tested the "old" httpapi and it works just like before, I think some pre-beta nightly builds had a non working httpapi and I wrongly assumed it was dropped from Dharma. Tolriq Wrote:And i reiterate my request that was discussed some times ago and mostly accepted, to getback some kind of thing similar to GetNowPlaying to avoid hamering XBMC with request (4 request per sec to get current player, volume , progress and media informations) that's a little too muchWouldn't it be possible to send multiple requests as one in an array as JSON-RPC 2.0 spec ("To send several Request objects at the same time, the Client MAY send an Array filled with Request objects.") edit: Woops... TOPFS2 about arrays: When it will be added is not decided yet but hopefully for eden. Nick8888 Wrote:1. working fine for me with whats in the wikiThings I used in HTTP-API that I'm missing in JSON:
I'm using EventServer for 1 and 5, multiple requests to get parts from 2 and 4 (might be possible with JSON, hopefully someone will answer my previous question about it), dropped everything else for now. And there are much more missing that I didn't use, but others probably do. Topfs2, could you tell a little more about the announcements? Is it possible to get more announcements? Ifso how? Which announcements are there? And once again, amazing job with JSON-RPC. Can't wait until the last objects are added and array support is in! - topfs2 - 2010-10-11 sWORDs Wrote:This might be problematic because it looks like there will be no way of telling when the return has been processed. Maybe counting { and } until the difference = 0. This is how we do it in XBMC atleast (when you as client send something). Also a tip overall when dealing with jsonrpc. there is no garantue in jsonrpc spec (although in xbmc there currently is) that your response will come in the order you send them. So what you should do is parse anything comming from xbmc and put them in json messages which you then react on depending of the id or action. Lots of extra code for xbmc though but would be future proof sWORDs Wrote:But I can't really find that much about the Announcements. http://trac.xbmc.org/browser/trunk/xbmc/utils/IAnnouncer.h Yeah the documentation about announcements are sad. Just grep the code for CAnnouncementManager::Announce sWORDs Wrote:
- sWORDs - 2010-10-11 Tnx for the reply! I only can find AnnouncementManager.cpp and AnnouncementManager.h. Is it in another directory or in a guilib? - topfs2 - 2010-10-11 sWORDs Wrote:Tnx for the reply! I only can find AnnouncementManager.cpp and AnnouncementManager.h. Is it in another directory or in a guilib? Should be plenty of calls to the announcementmanager made through out the code, for one example in application.cpp - sWORDs - 2010-10-12 Isn't it an idea to compact the return (or build it up compacted in the first place) before sending it? Code: { Code: {"id":1,"jsonrpc":"2.0","result":{"audio":false,"picture":false,"video":false}} And I think it could be helpfull to update the startpost of this topic with some extra information like JSON is in but not complete and mention the most asked for missing objects, and tell about the alternatives. Like the "old" httpapi that now doesn't accept POST but only GET, EventClient on port 9777 (eventclient.h). And also mention the RAW JSON tcp port on 9090. Might save a lot of questions asked over and over again. The RAW tcp port is extremely fast, on my (not very cpu powered) remote it's almost four times faster with small requests (partly because the socket is already connected and can stay open). And is there anything else available besides these?:
- topfs2 - 2010-10-12 sWORDs Wrote:Isn't it an idea to compact the return (or build it up compacted in the first place) before sending it? The json writer we have is perfectly able to write the shorter version, I opted for the styled writer since it was easier for me to debug, and I figured if it was easier for me it must be easier for the client creators I see no problem having an option to make it more truncated (or just always truncate on release builds). please feel free to make a feature suggestion and we can discuss how to best implement it. sWORDs Wrote:And I think it could be helpfull to update the startpost of this topic with some extra information like JSON is in but not complete and mention the most asked for missing objects, and tell about the alternatives. Like the "old" httpapi that now doesn't accept POST but only GET, EventClient on port 9777 (eventclient.h). And also mention the RAW JSON tcp port on 9090. Might save a lot of questions asked over and over again. Hmm, didn't realize old httpapi accepted post aswell, thats a regression. I'll look into it ASAP! From erhnam: LOL! I was seeing this as a new feature - sWORDs - 2010-10-12 topfs2 Wrote:LOL! I was seeing this as a new feature Maybe it's because english isn't my native language, but I really don't understand your quote and command. Is it cynical? Or is not accepting POST a bug? - topfs2 - 2010-10-13 Uhm, I got edited, think ernham meant to quote me ... need to yell at him. have fixed it now So what I WAS saying is that its an regression, I have committed a fix to trunk and is currently backporting it. thanks for bringing it to my attention And to erhnam, yeah I think accepting post is definatly wrong and its probably not sane security wise but backwards (mad) compability is probably sane. no point in forcing client creators to patch before deprecating - sWORDs - 2010-10-13 topfs2 Wrote:The json writer we have is perfectly able to write the shorter version, I opted for the styled writer since it was easier for me to debug, and I figured if it was easier for me it must be easier for the client creators
Once again, every comment I make isn't ment to bash your work in any way, I just would like to improve an already great feature and it's documentation. - erhnam - 2010-10-13 topfs2 Wrote:Uhm, I got edited, think ernham meant to quote me ... need to yell at him. have fixed it now Yeah sorry. I'm not very used at the quote and edit buttons since my status has changed. Sorry for that. I started building my xbmc php remote app just a couple of days and using only POST. |