2011-01-20, 06:57
wuench Wrote:JSON parsing from scratch IS difficult. My solution is probably going to be to give up on the raw socket interface and switch to HTTP, then you should only get a single response (or maybe limited number of responses) per request so it is easier to delineate messages, rather than an endless stream.
With no unique EOM, the socket interface seems like it has a high risk of getting out of sync if something gets mangled, even with a proper JSON parser. It will take a lot of extra code to protect against those issues.
TCP guarantees packet order and packet arrival, if it looses packets it will be resent and if it looses the entire stream it will give you a proper error for that. There exist proper stream parsers or you can use a proper jsonrpc client and it should work. That being said, http is usually simpler if you want to just use a parser.
Fiasco Wrote:You lost me. How is it a giant security failure?
Anyone having access to the database can both read, edit and completely destroy the database at a there leisure. This is something which is not at all good, something which should be sandboxed and impossible for a client to do unless explicitly allowed to do, which is what jsonrpc sets out the fix.
Fiasco Wrote:Yes, the table layout could change but tweaking a select statement is pretty straightforward.
It is, but why should a client need to do this at every release. i.e. it needs to first parse out what version XBMC is then it needs to create the select statement. XBMC handles this perfectly in the GUI code and a client should ideally be able to just ask "Get all movies" and the it should get them, no matter what version the database is. This is why jsonrpc is design how it is.
Cheers,
Tobias