[mythtv] json vs XML

George Nassas gnassas at mac.com
Sun Aug 18 02:51:17 UTC 2013

On 2013-08-17, at 10:28 AM, Joseph Mills wrote:

> I for one would hate to see the api just switched over to pure json.

There isn’t much value in this and besides there’s hardly any effort in supporting multiple return formats. It’s not like there is one function that implements /Video/GetVideoList for json callers and another one that does it for xml callers. Each phase of fulfilling a request is done by one generic piece of code which passes its work off to another generic piece until the result is ready for the caller.

For example /Video/GetVideoList places its resulting list in a binary data structure which gets passed off to a generic output routine. This routine uses a technique called “introspection” to examine what it has been given and pass on instructions to an xml writer or a json writer. With the video list it would see the first attribute is called “StartIndex” and it’s an integer so the json writer would get instruction to write “StartIndex” : 0, later it would see an attribute VideoMetadataInfos which is an array so it would write “VideoMetadataInfos” : [ and so on until the entire data structure has been output.

With this architecture when someone adds a new service endpoint they only code the binary data loading part and their routine will automatically know how to render xml, soap or json. Similarly, if the myth people wanted to support a new language or format, like lisp, it would be a matter of creating a new backend for the introspection function and voila all the service apis would magically support that new format.

One routine to look up the requested data, one routine to introspect it and one routine for each possible return format: that’s the smart way to do it.

> As there are many their party apps that use json. Maybe if there was a way to call the one you want to use example. Http://<yourbackend>:6544/foo?type=XML

Besides the path that you see (“foo?type=XML”) http also has something which appears in requests but users don’t typically see called “headers”. There’s a header called “Accept” which tells the server what format you want back. Giving “application/json” for the accept header tells the backend that you want your reply to be in json format. Soap and xml are also supported with xml as the default if you don’t send an accept header.

This is all standard stuff and is familiar to folks who noodle around with web services on a regular basis.

- George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130817/54468dcc/attachment.html>

More information about the mythtv-dev mailing list