Re:XMPP Myths
by jerf on Tuesday August 11, 2015 @02:00PM
(#10043117)
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.
""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.