+- 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
- hello_man - 2010-11-29
hey guys, are these apis available (going to be available) on xbox xbmc?
I would hate to implement my XBMC remote using Http api but if this is not in plan to move, I have no other option.
thanks.
- magnetism - 2010-11-29
You should probably ask that here. XBMC4XBOX has been split of from the main project.
- vaton4 - 2010-12-01
Kabooga Wrote:I'm currently going through the conversion of XBMControl_Web to use the JSON RPC API ...... I have most of XBMControl_Web ported over ....Hi, Kabooga, what the "most of" means here?
Asking because I am using XBMControl-web mostly for playing shared music files - no libraries, no video. May be this "allmost ported" version will be used this way?
I can accept even not fully working stuff and help with development.
Transfer encoding - pilophae - 2010-12-03
I'm trying to write a simple MPD gateway using the JSON-RPC API, but hit a snag when receiving filenames encoded in UTF-8 on the filesystem where XBMC resides. My XBMC instance is setup to use the encoding Western Europe (why is there no Unicode alternative?) and I found that the data sent via JSON-RPC could indeed be decoded with the cp850 encoding.
My question is, will this encoding change when I change the XBMC encoding, and can this be reflected with a 'Content-Encoding' header in the HTTP response in that case?
- blinkseb - 2010-12-03
pilophae Wrote:I'm trying to write a simple MPD gateway using the JSON-RPC API, but hit a snag when receiving filenames encoded in UTF-8 on the filesystem where XBMC resides. My XBMC instance is setup to use the encoding Western Europe (why is there no Unicode alternative?) and I found that the data sent via JSON-RPC could indeed be decoded with the cp850 encoding.
My question is, will this encoding change when I change the XBMC encoding, and can this be reflected with a 'Content-Encoding' header in the HTTP response in that case?
Hm, you're right, string depends on xbmc encoding. Two solutions :
* pass all strings as utf-8 / utf-16
* let strings encoding as it is, but add a json System.GetStringEncoding method
Let's wait for topfs2 answer.
- pilophae - 2010-12-03
blinkseb Wrote:Hm, you're right, string depends on xbmc encoding. Two solutions :
* pass all strings as utf-8 / utf-16
* let strings encoding as it is, but add a json System.GetStringEncoding method
I like solution #1 best, but what about sending the Content-Encoding in the HTTP response? That would keep the encoding information in the same channel as the data. It would make sense since JSON-RPC is a HTTP-based protocol.
Also, if XBMC keeps strings encoded in the selected encoding, must the JSON-RPC method parameters be in this encoding aswell?
- Montellese - 2010-12-03
pilophae Wrote:I like solution #1 best, but what about sending the Content-Encoding in the HTTP response? That would keep the encoding information in the same channel as the data. It would make sense since JSON-RPC is a HTTP-based protocol.
That's not correct. JSON-RPC can be used over HTTP but it can also be used over TCP (and probably any other transport protocol). TCP does not support any metadata concerning "encoding". IMHO the best solution would be to transfer everything in both directions in UTF-8 / UTF-16.
- blinkseb - 2010-12-03
pilophae Wrote:I like solution #1 best, but what about sending the Content-Encoding in the HTTP response? That would keep the encoding information in the same channel as the data. It would make sense since JSON-RPC is a HTTP-based protocol.
JSON-RPC is not always HTTP based. You can use it with a direction socket connection, so the Content-Encoding header is not a solution.
#1 would need reencode every strings before sending data, so a little overhead, but it may be a good solution.
Quote:Also, if XBMC keeps strings encoded in the selected encoding, must the JSON-RPC method parameters be in this encoding aswell?
In a perfect world, absolutely. But all JSON parameters use latin1 encoding (English alphabet), so encoding should not matter.
- pilophae - 2010-12-03
My bad. Didn't read the spec too carefully. In that case, the best option would be UTF-8 in both directions, IMO.
If I need to match a string, say a filename, in XBMC via JSON-RPC, must I first encode that string to the same encoding as used in XBMC before sending it?
XBMC: "Åland.mp3" (CP850)
Client: "\u00c5land.mp3" (UTF-8) -> "Åland.mp3" (CP850)
It would seem difficult to use the JSON-RPC API for international content if only the latin1 chars are available (barring content encoding)?
- blinkseb - 2010-12-03
pilophae Wrote:My bad. Didn't read the spec too carefully. In that case, the best option would be UTF-8 in both directions, IMO.
If I need to match a string, say a filename, in XBMC via JSON-RPC, must I first encode that string to the same encoding as used in XBMC before sending it?
XBMC: "Åland.mp3" (CP850)
Client: "\u00c5land.mp3" (UTF-8) -> "Åland.mp3" (CP850)
It would seem difficult to use the JSON-RPC API for international content if only the latin1 chars are available (barring content encoding)?
I'm not sure you can do such thing in JSON, topfs2 will say, but if you can, we certainly have an issue here.
I think you should not have to deal with character encoding, so best thing is to encode everything in UTF-16.
- topfs2 - 2010-12-03
Regarding encoding it comes down to what is speced for json overall afaik.
which is UTF-8 at the lowest http://www.ietf.org/rfc/rfc4627.txt (check section 3) so there should be no need to add a method for the encoding setting.
So if we don't send it as unicode thats a bug, you should always rely on it. In fact I'm pretty sure we will always send utf-8 and it would be quite a while (if ever) that we would use utf-16 and above. This because the most of the data sent is still english so utf-8 should save bandwidth (just a hunch).
As such cp850 should never be used, or supported.
As for parameters, I would say as long as its the same encoding as the rest of the json anything is ok. i.e. XBMC could send in utf-8 and client sends in utf-32 back, every message could be in a different encoding. But this is in a perfect world and I would not be surprised if that would crash something
Cheers,
Tobias
- pilophae - 2010-12-03
My specific problem is that the utf8 decoder in Python cannot decode the string returned by XBMC, but the cp850 decoder can. Is there a better way to ascertain what encoding I'm receiving?
- topfs2 - 2010-12-03
Would love some examples, might be that we don't return a proper utf-8?
(perhaps you could upload the exact received bytestream from xbmc somewhere?)
- pilophae - 2010-12-03
It seems I have some files in cp850, and some in latin1 in my filesystem. That explains that. Sorry to be a bother.
- topfs2 - 2010-12-03
Still, seems like we should handle it properly no matter.
So what did you have? I don't follow?