[hello_man]

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]

You should probably ask that here. XBMC4XBOX has been split of from the main project.

[vaton4]

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.

[pilophae]

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]

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]

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]

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]

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.

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]

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]

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]

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]

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]

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]

It seems I have some files in cp850, and some in latin1 in my filesystem. That explains that. Sorry to be a bother.

[topfs2]

Still, seems like we should handle it properly no matter.

So what did you have? I don't follow?