4 ms·
This XML / JSON markup combo looks so dirty: <message from="pubsub.fanout.io" to="alice@example.com" type="headline"> <event xmlns="http://jabber.org/p
by junto 13y ago
This XML / JSON markup combo looks so dirty:
<message from="pubsub.fanout.io" to="alice@example.com" type="headline">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="/d04fd503/test">
<item id="3ebc205b-ce77-46c3-843a-49e203e7945b">
<data xmlns="http://fanout.org/protocol/fpp">
{"foo": "bar"}
</data>
</item>
</items>
</event>
</message>
- est 13y agoreminds me of XML islands in Javascript <SCRIPT ID="XMLID" LANGUAGE="XML"> <XMLDATA> <DATA>TEXT</DATA> </XMLDATA> </SCRIPT> or E4X var sales = <sales vendor="John">
- ralphm 13y agoWhile yes, it may not excel in beauty, when do applications developers really need to look at, or implement, wire-protocols? Embedding JSON inside an XML element seems to be one of the least horrible things you could encounter. Binary protocols or base64 encoded blobs or SDP are arguably worse. As I mentioned in the other thread, if you want to make XMPP easier for application developers, things usually start with a well-defined API. If you want to, say, provide a simple API for doing publish-subscribe over XMPP, you don't really have to expose the intricacies of the XML-based wire-protocol. Most of the variables in this example (the addresses, the node identifier, the item identifier) can be exposed as simple attributes to a class representing a request, or as parameters to a function that performs the request. However, normally, the payload format is still expressed as an embedded XML document, like Atom or the various payload formats for User Location, key exchange, etc., as defined in a number of XEPs. Now, if your application just wants to be able to publish and/or subscribe to data easily expressible in JSON, why not just wrap that in a well-defined XML element, so that you can make your API as developer friendly as possible? And, if you really want to go all the way, you could even do some server-side translation between XML and JSON payloads so that pure XMPP clients can still play without having to deal with JSON. There are some more advanced features in the XMPP Publish-Subscribe protocol to express such translations.