Comment by zamalek | Hacker News Reader

Comment by zamalek | Hacker News Reader

Parent Full thread

> XMPP is not battery-friendly on mobile devices (this primarily has/had to do with the absence of push notifications, it seems).

There is actually an unbelievably good XEP (XMPP extension protocol) on mobile battery life.[1] I learned things from it: radio power states and so forth. It's incredibly detailed and educational and well worth the read even if you don't use XMPP. That being said, so far as actual implementations go, I have to agree with you.

> XML is unnecessarily complex for this kind of usecase, and too hard and time-consuming to work with (and I agree). That is most likely what 'slow' refers to - not slow in parsing it, but in developing for it.

I have an ever-evolving conformant XMPP server pet project. What I found is that the framework takes bloody ages and I have to agree with you there. However, XMPP is a protocol that is ripe for elegant architecture and you can make a great framework. If you spend the time making a good framework the protocol is an absolute pleasure to develop against: but you have to make that initial time expenditure.

> The correct technology is JSON-over-WebSockets, and it doesn't really make sense to compare XMPP to a known-bad implementation and say "see? XMPP isn't that bad!"

Sort of. XMPP is one of the few applications that actually really makes use of the "eXtensible" bit in XML (where it's often misused as a dumb object graph). This means that you can do something as follows:

    <message from='...' to='...'>
      <body>You have work, go to http://... to action it.</body>
      <form xmlns='urn:my-proprietary-stuff'>AF3BD2</form>
    </message>

Any client that doesn't understand the <form> element would ignore it and present the message (allowing the user to click-through to the web UI). A client that does understand it would be able to do the special proprietary logic. Servers are also required (AFAIR) to pass on that unknown XML unaltered. You'd at least have a few problems in JSON due to name conflicts - which you could work around.

Either way, XMPP inherits a lot of traits from XML. You either need it or you don't and if you are using it there is a good chance that you are misusing it.

[1]: http://xmpp.org/extensions/xep-0286.html

JSON name conflicts are easily resolved by giving every extension its own key in the object. That's the equivalent of namespaces.

I disagree. XML namespaces are URIs and give XMPP distributed extensibility. If you do this in JSON you are just replacing pointy brackets with curly ones.

I do think this is a clever solution (so have an upvote), but it's not exactly the same thing.

A lot of things get a bad name because they are used incorrectly. Look at SQL: it's actually great if you use it for the correct problems. The same thing applies to XML: if you're actually using it for the correct problems it's somewhat irreplaceable (XMPP is a beautiful example of how XML should be used).

Putting namespaces into JSON seems to fall into that dangerous territory - rather use the tool that's designed for that job from the ground up. JSON is great at the 99% of things that XML gets abused for, but it simply can't replace the 1% of correct use-cases for XML.

XMPP isn't a correct usecase for XML, though. It could easily be accomplished with a format like JSON without notable architectural defects. In a way, namespaces are a part of the JSON design - it supports deeply nested structures.

For a correct use of XML, I'd more suggest looking at static datasets with lots of complex inter-references and data types - for example, public transport data.

XML namespaces aren't just keys in a JSON hash, unless you're planning on naming all your keys like so:

    {"http://joepie91.com/XMPP/rtf_content content": "..."}

you're not correctly copying XML namespaces in your JSON. And that's not sufficient to correctly copy their capabilities, just a simple first-cut metric that shows you if you're not modeling it correctly in your head.

Further, you have to understand that the key thing about the XML namespaces is primarily social, not technical: The use of the URI in the namespace (which is otherwise just an advisory string with no meaning) is also a licence to stick things in the value that you fully expect no-one else to understand, in a way that you know is guaranteed not to cause a conflict (in the absense of hostile intent). The guaranteed lack of conflict gives you that license. If you intend to match that with JSON keys, you must either copy the XML namespace's approach or something very similar, or run the risk of stomping on each other's keys, which socially creates pressure back towards some sort of licensing mechanism/standards body where people must agree on things before they can be used. (XML namespaces are also important because URIs of domains you own are also one of the few relatively unique keys that you can get without permission from a central (XMPP) authority. It's not the only option, but it's worth observing that "just pick something!" still has problems.)

On the one hand, people have been complaining about XMPP for years and years... on the other hand, I'd point out that given that it is also surviving, one must ask the question "why?" And I'd submit that this may be a significant part of the reason why. If you want sane and correct extension on an IM protocol, XMPP is in fact the best choice.

> If you intend to match that with JSON keys, you must either copy the XML namespace's approach or something very similar, or run the risk of stomping on each other's keys, which socially creates pressure back towards some sort of licensing mechanism/standards body where people must agree on things before they can be used.

I understand the problem. I just don't feel that the way XML solves it is the correct one.

> (XML namespaces are also important because URIs of domains you own are also one of the few relatively unique keys that you can get without permission from a central (XMPP) authority. It's not the only option, but it's worth observing that "just pick something!" still has problems.)

Right, the point is that it's over-engineered. For usecases like this, you don't need guaranteed-unique namespaces - they just need to unique enough within your application that collisions are unlikely to ever happen.

For all practical purposes and intents, a key along the lines of `joepie91:carbons` (ie. a URN-like) would be sufficient - nickname and company name reuse is already non-zero but limited, and the cumulative chance of both having a name reused and working with the same kind of data (ie. conflict-sensitive) is negligible.

Domain URIs aren't quite decentralized (socially) either, by the way - in practice, it relies very heavily on the DNS system, which is very centralized.

> On the one hand, people have been complaining about XMPP for years and years... on the other hand, I'd point out that given that it is also surviving, one must ask the question "why?" And I'd submit that this may be a significant part of the reason why. If you want sane and correct extension on an IM protocol, XMPP is in fact the best choice.

"It's still around" in no way leads to "it's the best choice", logically. There are many, many reasons why an inferior, poorly-designed or overly complex protocol might still be in active use.

Conversely, it could be asked: why is XMPP not universally used, like HTTP is, and why is the tooling so substandard?

You've added in a lot of things to my post that I didn't say. Just to take one for instance:

""It's still around" in no way leads to "it's the best choice", logically."

Yes, I know. It's why I never made the claim that it's the best. I think XMPP has some serious flaws that kept it from being much more successful.

I also think XML isn't any of them. Convert XMPP naively to JSON, and it's still too difficult for people to bring up a stream and send an IM. One change I'd make, for instance, is for initiating a stream to default in one tag to a sensible initialized state, the state people expect a new IM stream to be in, and allow the user to override the defaults to be more manual, rather than what it is now. The spec is full of things like that, though, to some extent IM is a harder problem than people think.

"XML" is just a cognitively-available excuse. It's not the core problem. Personally, if I had to write a new protocol, JSON wouldn't actually be in the running; I'd either stick to XML or go to something like Protocol Buffers. I'd say JSON is actually in a really bad place for a big IM protocol, where it's still very, very verbose and has bad parsing characteristics (text-based, must parse whole message before you can do anything with it) but also fails at things XML is good at, like rich text and extensibility (JSON is bad at mixed text). And both are pretty bad at being streamed, for what it's worth.

"For all practical purposes and intents, a key along the lines of `joepie91:carbons` (ie. a URN-like) would be sufficient - nickname and company name reuse is already non-zero but limited, and the cumulative chance of both having a name reused and working with the same kind of data (ie. conflict-sensitive) is negligible."

That's not really disagreement. You just want to run the risk of using a shorter URN than everybody else, for the convenience of... uh... not sure actually, since this is all auto-generated JSON anyhow. It's not like you're saving the user typing, and choosing JSON means you've already thrown away wire-space efficiency. (Or are using gzip or something, and gzip'ed XML-XMPP and gzip'ed JSON-XMPP will be virtually identical in size on a stable stream.) You can already use that exact URN as an XML namespace today, if you so choose.

Reply on news.ycombinator.com