barrygordon Wrote:I assume if I use the raw port I would just send
/jsonrpc {"jsonrpc": "2.0" . . . "id": 1}

Any help that will allow me to get started would be greatly appreciated.

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 much

Tolriq.

Nick8888 Wrote:1. working fine for me with whats in the wiki

1. SendKey
2. GetCurrentlyPlaying (some items are missing in JSON)
3. GetGuiStatus
4. SetBroadcast
5. ExecBuiltIn (ActivateWindow)
   

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.

sWORDs Wrote:But I can't really find that much about the Announcements. http://trac.xbmc.org/browser/trunk/xbmc/utils/IAnnouncer.h

sWORDs Wrote:

1. SendKey
2. GetCurrentlyPlaying (some items are missing in JSON)
3. GetGuiStatus
4. SetBroadcast
5. ExecBuiltIn (ActivateWindow)
   

1. will be added at some point, just waiting for input refactoring to be done so that there will be a stable extension for jsonrpc to hook up with (no more of the weird bugs event server and other inputs suffer from).
2. is under discussion how and if to add.
3. most should be doable from the infobool, infostrings. Except running window.
4. level is setable in jsonrpc, with far better precision than httpapi (you enable/disable certain announcement classes).
5. Is left out since its impossible to wrap security wise. Could add it as a fallback but the security permission would be admin which really shouldn't be enabled by default security wise (so client would have to ask for it and that mechanism isn't available yet).
   

sWORDs Wrote:Tnx for the reply! I only can find AnnouncementManager.cpp and AnnouncementManager.h. Is it in another directory or in a guilib?

• HTTPAPI (80 http)
• vfs (80 http)
• JSON (80 http)
• JSON (9090 TCP)
• UDP Broadcast (8278 UDP)
• EventServer (9777 UDP)
  

sWORDs Wrote:Isn't it an idea to compact the return (or build it up compacted in the first place) before sending it?

Code:

{
"id" : 1,
"jsonrpc" : "2.0",
"result" : {
"audio" : false,
"picture" : false,
"video" : false
}
}

vs.

Code:

{"id":1,"jsonrpc":"2.0","result":{"audio":false,"p icture":false,"video":false}}

Both is 100% correct JavaScript and JSON code.

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.

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?:

• HTTPAPI (80 http)
• vfs (80 http)
• JSON (80 http)
• JSON (9090 TCP)
• UDP Broadcast (8278 UDP)
• EventServer (9777 UDP)
  

I'm still looking for a non http way to fetch fan and cover art. Would be great if I could use the HTTP-API in the RAW socket.

topfs2 Wrote:LOL! I was seeing this as a new feature

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

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.

1. Do you mean "XBMC Community Forum->Development->XBMC Feature Suggestions" or "TRAC Feature Request"? Compacted JSON means less data to send and lighter parsing for clients.
2. Maybe I could write some JSON and EventServer documentation?
3. And are there any control methods that I don't know off? (Besides the ones in the list above?)
4. There is another odd thing. With Camelot [LIVE] keypresses were send using f100 + ascii code. With Dharma [WINDOWS] f100 + ascii doesn't work, f000 + ascii does? (With EventServer and HTTPAPI sendkey)
   

topfs2 Wrote: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