On 2013-10-09 19:45, Ralph Meijer wrote: > Please don't top post. Reformatted below. > > On 2013-10-09 18:58, DOI Yusuke wrote: >> On 2013-10-09 18:46, Maxim Ignatenko wrote: >>> On 9 October 2013 16:20, XMPP Extensions Editor <[email protected]> wrote: >>>> Abstract: This specification defines an element to be used for > encapsulating JSON data in XMPP. >>> >>> What's the intended purpose of embedding JSON into XMPP stanzas? >>> Provide a standard encapsulation for things like Google Cloud >>> Messaging? >> >> I feel it's better to define a standard method to encode arbitrary >> content type <content type="text/json">{}</content> than defining >> <json> tag specifically to say 'this is JSON'. >> (I'm not sure if there are such spec already or not) > > First off, arbitrary content cannot be represented in XMPP like that, as > it doesn't embed binary data nicely. But see Justin's reply for that, as > well. > > The primary use case for me is in publish-subscribe. There, you must > have a containing element for item payloads, and specifying one > dedicated to JSON makes a lot of sense to me. If you read today's > article by Justin [1], you can easily see why. > > As mentioned in the comments over at HN [2], if you want to make things > easy for (web-)developers that like to deal with simple APIs without > having to craft XML for payloads this really helps. Now the API is > basically a destination address for the Publish-Subscribe service, a > node identifier, optionally an item identifier and the payload as JSON. > Doing a generic <content/> with mime type and encoding seems over-design.
[1] http://blog.fanout.io/2013/10/09/publishing-json-over-xmpp/ [2] https://news.ycombinator.com/item?id=6520524 -- ralphm
