XMPP Myths
wiki.xmpp.org
wiki.xmpp.org
1. XMPP is not battery-friendly on mobile devices (this primarily has/had to do with the absence of push notifications, it seems).
2. 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.
Neither of these are addressed.
I also don't really understand the comparison with "JSON over HTTP" - why would you ever use that for a realtime application?
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!"
Another issue with XMPP is the strange implementation of both resources and the existing options for sending to all resources (especially when taking into account tools like OTR). People want device synchronization, and it just isn't viable with XMPP right now.
> XML is unnecessarily complex for this kind of usecase
XMPP is too complex, but the XML stuff is really the smallest issue, compared with other complexities in the protocol. For example, every client that successfully connected to an XMPP server must first send a "<presence>" message. Otherwise, it won't receive any messages despite their successful connection. And there are more such surprises in XMPP. Good luck in understanding which "devices" (#xxxx) of the same Jabber ID will receive a message targeted at that ID.
It's really annoying and discouraging to debug that kind of issues - especially since these aren't bugs. These work as specified, but the specifications were obviously designed with direct human chatting or direct human collaboration in mind, programs being an afterthought.
> The correct technology is JSON-over-WebSockets
Not really. Whenever I saw someone trying this "in the wild", I see them quickly switching to HTTP long-polling. (Not to be confused with polling! We are still talking about instant push notifications with very low network overhead.)
For example, there are some libraries that used to provide wrappers around WebSockets, which switched to HTTP long-polling as fallback for old browsers. Nowadays, it seems they use long-polling by default, even though browser support becomes better and better.
Don't underestimate the role of firewalls and HTTP proxies! Many firewalls are aggressive configured, and many companies have forced HTTP proxies in place.
EDIT: Hmm, did you edit your post? I don't recall the first part being there... anyhow:
> XMPP is too complex, but the XML stuff is really the smallest issue, compared with other complexities in the protocol.
That is one factor, but the protocol complexities often seem to derive from the question 'how do we represent this in XML?', and that's an issue.
Another problem is the jargon - the MUC specification is utterly incomprehensible, because the terms it uses for things are so wildly different from how they are used everywhere else, that building a mental model is really hard. I've seen this issue in other XEPs as well.
That statement is wrong. Sending an initial presence merely indicates your availability to entities subscribed to your presence. Not sending the initial presence does not prevent you from receiving message stanzas.
But it's certainly not true that you "won't receive any message despite ... successful connection".
There is unneccessary complex behaviour in XMPP that you must write extra code in your client for. Otherwise it will work mostly, but not always and not reliably.
Dave Cridland's wiki page makes some good points, but predictably it paints a very black and white view of the world. Some contentious points are:
1. Myth One: XMPP is XML, so it's too slow.
...there are obviously faster encodings than XML out there (e.g. CBOR), so this feels like a slightly specious point to argue. Sure the difference isn't that important on the clientside (perhaps more of an issue for squeezing every last drop out of a server), but why not acknowledge it?
2. Myth Two: The baseline is minimal, therefore XMPP is useless.
I'm not sure anyone claims XMPP is useless just because its baseline is minimal. The issue is instead the fragmentation caused by lack of interoperability profiles for all the different extensions. Statistically, if I pick an arbitrary XMPP client and an arbitrary XMPP server, the overlap of supported XEPs is unlikely to provide a good modern comms experience. If it was a "bug" for your client or server not to implement a given critical XEP, then fragmentation would be less of an issue.
3. Myth Three: It's too bandwidth-inefficient for mobile.
Just because you can successfully talk XMPP over a 9600bps link with 30s of latency doesn't mean that the default transport is bandwidth efficient(!) That said, the XEPs for constrained networks are a better justification.
4. Myth Four: XMPP is unreliable without a bunch of extensions.
As Dave repeatedly says, XMPP is a NAK protocol - by default messages are not acknowledged, so whenever a TCP stream drops you have no way of knowing whether the last messages in the stream got through or not. This is to me the definition of an unreliable delivery mechanism, and you have to mitigate it with extensions (XEP-198). I'm still not sure how this one's a myth...
5. Myth Five : XMPP is unsuited to the web.
The hypothesis of "XMPP is unsuited to the web because angle brackets and stuff" isn't exactly well articulated here. I think the actual complaint here is "why bother putting an XMPP stack in your browser when you already have an HTTP stack there"? What value do the remnants of XMPP's transport semantics have when you already have HTTP as a transport? I agree that Stanza.io & XMPP-FTW make this less clear cut, however.
For what it's worth, the FAQ entry that triggered this wiki page can be found at http://matrix.org/blog/faq/ (What’s the difference between Matrix and XMPP?).
As to your comments:
(1) I'm just not seeing this. Even without mobile-style push, apps like Conversations appear way down the list in Android. Note that because XMPP maintains a continuous TCP session (or WebSocket, or whatever), then you get "push" in a general sense; that is, there is no polling.
Using an XMPP client on your mobile will, of course, have an impact on battery life, but I don't think a good client will drain your battery. For me, Conversations uses less power than Solitaire according to Android.
(2) I'll agree that XML does make the development of XMPP libraries more complex, but we gain because it grants very simple permissionless extension capability, and that's hugely valuable. If developers working with (rather than on) XMPP are having to hit XML directly, that is absolutely a problem.
Finally, resources are the way they are for all sorts of reasons, but Message Carbons really does work for having conversation sync across multiple devices. I often walk away from my desktop and continue conversations on my mobile and/or tablet, and wander back to the desktop when I feel the need to continue with a keyboard.
Hope that helps.
> Using an XMPP client on your mobile will, of course, have an impact on battery life, but I don't think a good client will drain your battery. For me, Conversations uses less power than Solitaire according to Android.
I don't know how accurate Android's power estimates are, but I consistently have people telling me that they are switching back to proprietary messengers because every XMPP client they've tried drained their battery. Whatever causes it, there's a real problem here.
> (2) I'll agree that XML does make the development of XMPP libraries more complex, but we gain because it grants very simple permissionless extension capability, and that's hugely valuable. If developers working with (rather than on) XMPP are having to hit XML directly, that is absolutely a problem.
The problem is that theoretical future benefits are worthless if you never get a base implementation going. XMPP is just too hard for many developers - it's not a thing that you're going to understand well unless you work on it full-time, and that's not acceptable for a protocol.
Hitting XML directly is almost always a requirement. Libraries are woefully incomplete due to the large number of XEPs, and to implement anything yourself, you must understand the XML structure.
If the intention of XMPP or XMPP frameworks was to abstract away the XML, then they have failed.
> Finally, resources are the way they are for all sorts of reasons, but Message Carbons really does work for having conversation sync across multiple devices. I often walk away from my desktop and continue conversations on my mobile and/or tablet, and wander back to the desktop when I feel the need to continue with a keyboard.
I experience constant issues with OTR, most servers don't seem to even support message carbons (nor do major clients like Pidgin have any useful indications of it), and frankly, I have never seen a single 'regular' user get synchronization set up correctly.
This is really a pervasive problem in the XMPP ecosystem: everything is too hard. Little to no thought seems to have gone into the UX, and unless you are an 'experienced XMPP user', you really have no clue what is going on. The experienced users say "meh, works for me" and don't set out to fix it.
This is true for the frameworks, the clients, and most of the servers. It's just all-around user-hostile, and that needs to change.
You have to differentiate between the specification and the implemetation. Nothing in the XMPP specification prevents you from implementing a battery friendly XMPP client. But some implementations suck/have room for improvement.
Where that problem is, I don't know. I'm just going by what I hear from people more experienced with the effect of XMPP on battery life.
I honestly cannot help you. Could be that my usage patterns just happen to make the battery usage better (though I'm a heavy user of multiple accounts), or could be I'm a really serious Solitaire player.
I do know that over the past year or so the situation has really improved, though (mostly with the merging of aSmack and Smack, but Conversations too).
> The problem is that theoretical future benefits are worthless if you never get a base implementation going. XMPP is just too hard for many developers - it's not a thing that you're going to understand well unless you work on it full-time, and that's not acceptable for a protocol.
I mostly agree; I'd hope that we could get to a place where the requirement to "know" XMPP was roughly that of needing to "know" HTTP. So simple use cases could be done without truly understanding the guts.
> Hitting XML directly is almost always a requirement. Libraries are woefully incomplete due to the large number of XEPs, and to implement anything yourself, you must understand the XML structure.
> If the intention of XMPP or XMPP frameworks was to abstract away the XML, then they have failed.
I'll confess to not being your typical XMPP developer, but I was under the impression that successfully hitting the XML with libraries like Smack was actually quite hard.
> I experience constant issues with OTR, most servers don't seem to even support message carbons (nor do major clients like Pidgin have any useful indications of it), and frankly, I have never seen a single 'regular' user get synchronization set up correctly.
OK, so Pidgin is a multi-protocol client which means the UI is abstracted out... But... https://developer.pidgin.im/ticket/15508 I don't understand their logic there, I have to say.
For OTR, by the way, that just breaks with multi-device anyway. There's some experimental work with Axolotl underway which looks very promising.
> This is really a pervasive problem in the XMPP ecosystem: everything is too hard. Little to no thought seems to have gone into the UX, and unless you are an 'experienced XMPP user', you really have no clue what is going on. The experienced users say "meh, works for me" and don't set out to fix it.
I won't disagree there. The lack of a consensus on UX considerations (in fact, the lack of any attempt to get such a consensus) means that different clients present even simple things like jids differently. That's something the community (or the XSF) could seek to address.
> This is true for the frameworks, the clients, and most of the servers. It's just all-around user-hostile, and that needs to change.
And again, I agree. It's sad, especially, that you qualify servers yet not the clients - I'd rather see clients as really easy. I mostly think Conversations is there, mind, but I'm hardly the target audience here.
That said, I'm aware that one key problem faced by a federated network is that client on-boarding can't, so easily, create your account for you, and early attempts to streamline that process have left serious abuse problems in their wake.
For another example, Mumble (VoIP) is effectively leader in bandwidth, quality, encryption, and extensibility - but have you ever tried to teach an end user gamer or otherwise about certificates, checking cert fingerprints, backing up their client certs so they don't lose admin privileges on servers, it's more or less a UX/onboarding clusterfuck.
UX should be a high-priority item.
I'm afraid that will never happen, though, due to the way extensibility is built into XMPP. HTTP is only very superficially extensible - you can provide custom headers (which are really just formatted strings) and custom-encoded body data. Both can be rather challenging to understand, in some cases, but the core protocol is easy to abstract, and usually is all you need.
For XML, that is much harder - without the right set of XEPs, XMPP isn't very useful for a real-world application. If only one single XEP is not implemented on your platform, you have to write your own, and immediately have to deal with the entirety of the XMPP/XML (protocol) design. You can't superficially string something together, like with a HTTP header.
> I'll confess to not being your typical XMPP developer, but I was under the impression that successfully hitting the XML with libraries like Smack was actually quite hard.
Things seem slightly more well-supported in Java-land, but in most other ecosystems, there are no implementations of XMPP that are both feature-complete and easy to use. A complex protocol invites developers who build complex abstractions, not easy ones.
> OK, so Pidgin is a multi-protocol client which means the UI is abstracted out... But... https://developer.pidgin.im/ticket/15508 I don't understand their logic there, I have to say.
I have no idea, but some of my contacts use other clients, and they haven't gotten it to work either.
> For OTR, by the way, that just breaks with multi-device anyway. There's some experimental work with Axolotl underway which looks very promising.
Depends. XMPP seems somewhat lacking in its notification of which resources are 'active' (in common implementations), which is something that would help to at least synchronize online devices (by sending differently encrypted messages to different resources). Log synchronization is trickier, but really should be possible as well.
> I won't disagree there. The lack of a consensus on UX considerations (in fact, the lack of any attempt to get such a consensus) means that different clients present even simple things like jids differently. That's something the community (or the XSF) could seek to address.
I am not just refering to end-user UX, though - also to developer UX. Complex protocols with complex libraries aren't developer-friendly, and the same issue occurs as above: complex abstractions invite developers who write complex end user products.
It's very hard to get simple end user products built for complex protocols, because those require two fundamentally different types of developers.
> That said, I'm aware that one key problem faced by a federated network is that client on-boarding can't, so easily, create your account for you, and early attempts to streamline that process have left serious abuse problems in their wake.
I think the big mistake there was to leave the exact registration data undefined. Rather, there should have been a standardization of 'common registration fields' (including eg. CAPTCHA data), and later amendment XEPs if things like CAPTCHAs were to have to change.
As it is, in-band registration is disabled almost everywhere, because no client can deal well with bot prevention measures.
IRC and MSNP (the early versions, before they started XML-ifying everything) are what I'd consider a good format protocol for the application - a mostly line-based, textual one you can use pretty easily without any client more complex than netcat. They are also extensible enough even without XML.
(Personally, I think it is absurd that a protocol needs to wrap a single text message, the most common form of message that would be encountered, in several times more bytes than the message itself.)
You will need some kind of serialization format for a reliable message protocol. JSON is just the simplest possible format that can reasonably represent common data, and works in 95% of the usecases.
[1] http://msgpack.org/ [2] https://github.com/raypulver/LEON
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>
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.
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.
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.
{"http://joepie91.com/XMPP/rtf_content content": "..."}
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.
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?
""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.
No, it's ASN.1 DER over TCP. :)
I really do wish that canonical S-expressions had won over XML for data transfer (as opposed to publishing markup): much more readable, incredibly easy to parse, fairly lightweight. Really, nothing wrong with them except for some reason people seem to be allergic to parentheses.
Why is that? Is it that one has to hit shift to type them on a standard keyboard?
I'd argue that S-expressions are used by simple software that solves complex problems, but I'm a bit biased
What is 'difficult' in XML?
JSON can be very easily natively represented in just about any language: you have objects/hashmaps/dicts, arrays, booleans, strings, numbers, and null. This means that accessing something in a JSON object is simple - you just use standard member access in your language of choice.
XML is considerably harder to use - you have children, and attributes. You have namespaces, and so on. These make it impossible to use a basic 'data model' like for JSON - instead you need interactive objects, that let you traverse the tree.
You can no longer simply map/filter/reduce over data. You can't easily access deeply nested structures without lots of syntax clutter. You can't easily serialize back and forth. Instead of using what your language already provides for data structures, you now need to learn an entirely new one, specifically for XML.
That is what is 'difficult' in XML - it considerably increases the cognitive load for working with it. You can't keep the structure in your head easily, but need to look at documentation instead, and need to learn a specific (often bulky!) API just to interact with the data.
Realistically, XML is useful for storage of complex data, but you really shouldn't be using it for wire serialization like XMPP does. XML is useful in a small subset of usecases, and trying to apply it to everything else is a mistake.
This makes it possible to experiment over the live xmpp network.
map/filter/reduce etc is possible with XML. Scala does it. Other languages can do it to. It's purely depending on your language. Even JavaScript has better XML support than the language you're portraying here :-)
Sure. The problem is that in every implementation I've seen, they're unreasonably hard to work with. Giving each extension its own key in a JSON object accomplishes the same, without breaking the native data model.
> map/filter/reduce etc is possible with XML. Scala does it. Other languages can do it to. It's purely depending on your language. Even JavaScript has better XML support than the language you're portraying here :-)
Yes, it's possible, but it's too hard. It always introduces more complexity when compared to standard deserialized JSON (in any language that can natively represent the JSON data types, which seems to be most).
Just like Generics.
Java, for example, does support Optional types similar to Haskell’s Maybe.
Haskell in supports them, too
No, it's not the biggest challenge but it's so transparently a case of conplete disregard for developer productivity that I've heard it mentioned by a lot of people as why they avoid XML.
This is the core issue with XML/XMPP. UX simply doesn't seem to have ever been a factor when designing either of them - whether towards the developers or the end users.
(XMPP would've used JSON had it existed in 1998, fwiw.)
Yes – in particular, I remember liking the initial promise of XML 1.0 and then being disappointed as the initial simplicity was buried under layers of gratuitous complexity as the enterprise computing crowd jumped on board. Some neat ideas (e.g. XPath)
Similarly, my first database-backed web app was a Java servlet in 1996. I assumed it would become richer in the future but it was still pretty easy write and deployment was pretty simple at that point. Instead, the community chased off after more complexity (JavaBeans, the near-pervasive obsession with runtime configuration and the ensuing massive config files, nested abstraction layers, etc.) rather than focusing on basic developer productivity. We got massive piles of code like RMI (i.e. CORBA) before basic features like regular expressions, logging, etc.
> Could we have built anything on the scale of the web with CORBA?
No. We also failed, repeatedly, to do it with XML for reasons which are obvious to anyone who's ever used SOAP/WSDL/etc.
The common theme was seeing complexity and, especially, abstraction as a universal good rather than something with real costs and forgetting how important high-quality implementations are, particularly when you're relying on them to help with all of that complexity.
Rich Hickey did a great service outlining some common problems when thinking about the word complexity itself: http://www.infoq.com/presentations/Simple-Made-Easy
I don't think it's about the engineers wanting to see complexity, so much as the problems you mention stemming from design-by-committee.
The web is a lot of things, but broad consumer adoption of web technology also involves boring things like banks. SOAP and WSDL weren't created in a vacuum. They exist because Java / XML made it even possible to bridge the gap from the old world.
As much as we like all sorts of features of the web, integrating commerce was what brought the enterprise in, drove down costs, etc etc etc.
And yes, you absolutely do have to use namespaces when working with a third-party protocol that chooses to use them. You can't opt out.
This is how we have the rapid trends in this field, where the new panacea is tomorrow's nightmare.
By the way, XMPP predates JSON or at least stems from a time when JSON was not jet standardized or widely accepted, so at least in the context of XMPP the XML vs JSON debate is pretty futile to begin with.
Realistically, it's completely understandable that XMPP was built on XML, and it made perfect sense at the time - but that should not preclude us from acknowledging that there are serious usability issues with it.
The significance of cognitive load in software development is well-understood, so it seems you're barking up to the wrong tree.
Yes, making things 'simpler' at the cost of architectural issues is bad - but that does not give you a wildcard to claim that complexity doesn't matter, as you seem to be doing right now.
A protocol like XMPP could easily use JSON without any significant architectural issues resulting from it.
Screaming "get off my lawn" to anybody who cares about developer efficiency, without any rational arguments underlying it, is not going to encourage them to use XMPP. It will just make them see you as a hostile dick that they don't want anything to do with. And that is not an insult - that is the reality of how people interpret these kind of posts.
If you'd want this property in a JSON-based wire protocol, you'd invariably going to end up with XML-in-curly-brackets. This is why developing with/for XMPP is slightly harder than a protocol that has a limited feature scope.
However, as Dave mentions elsewhere, one shouldn't have to deal with the wire protocol directly to use XMPP in your application. A proper library should abstract from that. Arguably in some platforms, that's still a weak spot.
Yet there was none. Your very post, though, not only attempts to paint my comment as an "old person thing" (hilariously), it then attacks the speaker ("hostile dick"). Before you (incorrectly) start claiming fallacies, maybe commit to witholding them yourself.
My comment absolutely rises defensiveness among some people. But this is an endemic issue in this industry, and your personal feeling of diminished professionalism in the face of it needn't merit attack responses -- countless projects chose technologies not because they were efficient in any real world sense of that word (saving 15 minutes on the first day to pay thousands of hours later is hardly anyone's measure of "efficiency", and that you attempt to attack the very clear statement I made boggles the mind), but because they were the laziest, most accessible option available, saving a tiny amount of effort at the forefront.
Generating code is easy. Generating tonnes of code is easy. Generating good, well considered solutions, learning and adopting appropriate technologies and choices...well that's hard.
There was. You were painting an overly ridiculous consequence of the argument, and then arguing against that overly-ridiculed consequence.
> Your very post, though, not only attempts to paint my comment as an "old person thing" (hilariously), it then attacks the speaker ("hostile dick").
As I explicitly pointed out, that wasn't an insult. It was a pointer as to how other people will likely interpret your comment. Which was more or less confirmed by the downvotes on it.
I wasn't attacking you. I was trying to make you understand how other people would read your comment.
The rest of your post again uses an overly ridiculous version of the argument to argue against (that really has nothing to do with my original statement), so there's really not much point in me responding to that.
The R5RS Scheme specification w/ example code: 50 pages
XML 1.0 specification for structure only: 49 pages
Sun's efficient, binary XDR: 29 pages
Wirth's Oberon Programming Language spec: 21 pages
ECMA JSON specification: 14 pages
Jsmn - portable, JSON parser [2] in C: 7 pages
I'm sure the above illustrates quite well how difficult and complex XML is. Additionally, while students everywhere implement LISP, there's a whole chapter in Beautiful Code where writing a good XML parser is an accomplishment people pay to see. Far from minimal understanding, reading XML's specification is a HOW-TO guide for how non-programmers that haven't seen superior works (eg Scheme, Oberon) try to handle data management. It was horrible, I used s-expressions/XDR instead, and implemented whole thing in a few hundred lines of straight-forward code. Best of all, unlike XML, my code could've run through a tool to prove it free of the types of bugs hackers love to exploit.
So, there's my proof that XML is garbage. Essentially everything it does can be done better by using one or more tools with less complexity, more cost-effectiveness, and more straight-forward implementation. Nobody should waste time learning it. If work demands, they should just learn a library that handles the awful details for them and internally use something else. Also, they should avoid any protocol that depends on it: that's just bad design.
My post will be pummeled by the defensive, and that's okay.
> The notion that binary serialization is difficult comes from the most profoundly lazy evaluations possible, where the most minimal of up front understanding are effort are eschewed if you can just open a text file and insert some giant mystery meat bags of XML.
etc etc
I never really understood this complaint. Why are the notifications sent via XMPP's TCP channel not considered "push"? How do you expect to get push notifications without an open TCP connection anyway?
It's a form of batching.
Instead of something like a network traffic scheduler or a signal that the radio is on and now is a good time to send stuff.
I do use XMPP in a mobile environment without any noticeable impact on battery runtime. It's not the protocol which drains your battery, but how one uses it: If there is frequent activity in terms of XMPP stanzas being exchanged between your device and the device's XMPP server, then the device will be unable to e.g. put the radio to sleep. Which, in turn, is of course causing battery drain.
The golden rules to prevent that:
1. Only send XMPP stanzas when necessary
2. Bundle and defer outgoing stanzas if possible
3. Tell your XMPP service when the device is inactive, so that the service is able to optimize the traffic (XEP-352: Client State Indiation [1])
4. Consider service-side stanza blocking (e.g. XEP-16: Privacy Lists) for stanzas of "unknown" origin to prevent malicious users from draining your battery.
1-3. Could be solved with upcoming versions of XEP-313 MAM.
4. e2e There is currently a XSF GSOC project running, bringing axolotl to Conversations (and eventually describing the protocol as an XEP).
5. There are a few standards on how to perform encrypted file transfers, but implementations are lacking. You are invited to code one.
6. XEP-357: https://xmpp.org/extensions/xep-0357.html
One of the complainers is matrix (https://matrix.org/), which does JSON over HTTP.
Oh, and I'm eager to see how their API survives mutual parties extending it. (There is a reason why namespaces exists)
Matrix uses namespaces for extension to survive mutual parties extending it (http://matrix.org/docs/spec/#events), and we haven't seen any problems there yet.
That said, Matrix is still beta and we certainly do have a whole bunch of other problems :)
If you are connected and your buddy sends a message you get it right away.
And on a data connectivity change, e.g. GSM <-> WiFi switch, there is a good chance that a dozen other components start trying to re-establish their connections, which means the radio is awake anyway (for, usually, at most a few seconds).
An idle connection doesn't consume anything, but a useful idle connection will have some keepalive every X minutes. Multiply that by the number of connections your application will have and by the number of background application you run on your phone, and the radio will never truly sleep or enter the "low" mode. The solution wanted by Google and Apple is to maintain a single connection to their server on which every push is aggregated and sent, and that the OS itself manages.
> Multiply that by the number of connections your application will have and by the number of background application you run on your phone, and the radio will never truly sleep or enter the "low" mode.
Why would X x Y idle connections (X: TCP connections per app, Y: applictions) prevent your radio from sleeping?
In the worst case, if the pings aren't sent at the same moment and all applications have a timeout set to, let's say, 30 minutes, your phone will send a ping every 30/(X*Y) minutes. I don't know what the usual X and Y would be, but if they're high enough your radio will always be up (check out these slides, 23 in particular: https://www.igvita.com/slides/2013/io-radio-performance.pdf)
And that's only counting idle applications. If you have one that periodically polls a server, it gets even worse.
Hi. I'm Dave Cridland. There's a note just up there which says "(Draft blog post)", and that's been there from the start - but when I asked for some feedback from the public standards@xmpp.org mailing list, people posted it on Twitter, and then it got onto Hacker News. Which is all cool, it's not secret, but...
This has not been properly reviewed yet (though the community is starting to), and so may contain inaccuracies, errors, or simply bad wording that's inadvertently as misleading as some of the comments I'm trying to rebut, and so feedback is genuinely welcomed.
Also equally welcome is feedback of the kind that says "Yeah, but I think that XMPP is entirely made by KILLING KITTENS", or whatever, so I can either write a rebuttal, or agree with you and try to get the community to fix it.
This is, currently, my personal opinion, and may not represent that of the XMPP community or the XMPP Standards Foundation.
Just for the record, I don't think we kill any kittens.
XMPP is sort of similar to all the browser technologies (HTML/DOM/CSS/etc.): it’s a large and complex spec which takes a large amount of work to implement even a basic version of, with lots of possible things to screw up.
It mixes various concerns together into a big jumble without the cleanest layering, which makes certain types of systems a pain to build on top of it. It’s based on a technology (XML) which is inherently heavyweight and not all that well suited to streaming applications. Tooling which exists around XML is mostly fairly irrelevant to an XMPP-like use case. If someone wanted to make an open IM protocol from scratch, they could make something much simpler, cleaner, and better organized.
On the other hand, all the other popular person-to-person IM protocols are proprietary, and XMPP is at least open, reasonably well documented, and with a relatively large community built up around it. Which counts for a lot.
If someone wants to build a new protocol, for example Google Wave, I would very strongly recommend against trying to shoehorn it into XMPP. On the other hand, if someone wants to make their chat client or server interoperate with existing chat networks, then XMPP is great.
[1] https://github.com/WhisperSystems/TextSecure-Server/wiki/API...
I am gonna make my grumpy old man. It still takes 1 day for an apprentice coder to :
- make an irc bot; - program a rs232 port; - to draw a pitcure accessing a framebuffer; - to make hello world in Tcl/Tk that is centered horizontally and vertically in a bigger canvas.
But seasoned devs cannot easily do the same with:
- xmpp; - usb; - css/js...
Either the quality of the devs is going down, or some progresses are not.
ADDENDUM technical issues in jabber: http://webcache.googleusercontent.com/search?q=cache:yGdLTF4...
Does this device require a null modem cable?
When the manual said that all commands needed to be terminated with a '\n', did they actually mean "\r\n" and not mention it?
Am I sending ASCII bytes to a piece of hardware that expects strings of UTF-16, without documenting it?
Did one of the students swap the cables and I'm just talking to a deactivated motor controller?
Has this particular serial cable finally bit the dust?
Is the hardware expecting me to transmit data on pin seven for some ungodly reason?
Did one of the students swap the the detector cable and the pre-amp high voltage line and fry the board I'm trying to talk to?
These are all issues that I've had to contend with on serial communications. The big catch is that it's usually not just one of these problems, so I wind up needing to check every possible combination. Having a device on USB saves me a boatload of trouble. The devices hooks up to the computer through a single, standard type of cable. If I can see the device after I plug it in, it's a software problem. If I don't see it, there's a hardware problem. Just from the above scenarios, seeing the equipment NOT connect eliminates 75% of the phase space for the problem. If I DO see the hardware, I've cut out 96%. So much easier to debug with USB.
It's sad, because we don't have that many decentralized multiplatform protocols. I had high hopes for Signal, but so far there is just one closed server.
Actually making the complex and simple stuff coexist on the same system is a very... complicated challenge.
Would things be better if they were worse?
That is, what if we gave a little bit less of a shit about optimizations and preferred simple over fast?
We live in a world of magical black boxes that even experts in the field have trouble manipulating. We need to protect and promote the Freedom to Tinker and that means carefully considering when optimizations are really critical hindrances.
:-)
On the other hand, both stanza.io and XMPP-FTW both use the same fixed-format (ie, inextensible) JSON format for XMPP just fine. They can do this because they drop unknown namespaces and don't intend to provide round-trip conversions, etc. So if you're after a JSON "interface" to XMPP, there is one, and it's pretty good.
Worth a look.
EDIT: Also the X in XMPP stands for eXtensible not XML
I think it showed how its complexity vs value delivered tradeoff isnt so good. Decided against trying to implement the protocol.
(a) it's improved remarkably and such short comings don't exist
(b) it won in adoption, it's getting all the labor, and you two are simply trying to improve it on the technical council.
I'm going with (b) for now. Was I right? Or is XMPP now efficient, easy to understand, and easy to implement?
I'd note that I was never against XMPP, though; I just don't see the need to pretend it's perfect. I do, however, object when problems are claimed for it that it doesn't have.
I have to mention the Conversations people. For me they are a big reason why i use xmpp. It's not only the client which is very good, but the stuff like http-uploads fix some very real problems in very little amount of code.
Also once axolotl-xmpp works and prosody 0.10 is released i see no reason not to use xmpp honestly, which i will regardless, even if everybody uses something else (like WhatsApp) i will simply write myself a transport server and continue to use Conversations.
While i don't use it, projects like biboumi are realy cool. With a simple combination of biboumi[1] and httpuploadcomponent[2] you now can share files in irc-rooms.
I still have more to say. I hope that once i have my perfect chat-setup i will write about it.
[1]: https://github.com/louiz/biboumi [2]: https://github.com/siacs/HttpUploadComponent
"Merlin" might or might not be based on any historical figure, and such figure might or might not lie under that hill, and if so he probably knew a few Angles, but he never heard of "England", because it didn't exist for centuries after he might or might not have been active.
If you want to be pedantic, Merlin - assuming he existed in the most likely timeframe - probably was aware of Angleland to his east, and would have been defending against its encroachment. (This based on the rise of Arthur as a popular name around 550AD as I recall, during the "Saxon" invasion largely carried out by Angles). The country he lived in was probably called something like Britain, though may have simply been closer to Cymru.
But I was largely paraphrasing T.H. White's Once And Future King, which in turn cribs the La Morte d'Arthur, which forms the basis for the "modern" Arthurian legend, and recasts it in an idealized England.
Honest question for edification and future play around projects: what alternatives do exist, fixing the issues presented here?
I'd love a lean, multiplatform api, with presence, multi-user chat, extensible for my use case, etc.
Recommendations?