8 ms·
XMPP Myths
- SFjulie1 11y agoApparently for me it is a myth that XMPP teams can make anything that works. And their site is logically down. 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:yGdLTF4J8DEJ:about.psyc.eu/Jabber&hl=en&gl=ca&strip=1&vwsrc=0 http://webcache.googleusercontent.com/search?q=cache:yGdLTF4...
- nextos 11y agoThis is so true. XMPP is quite complex. Complex to the point that bringing up a possible bug on either GTalk generating XML or Mcabber parsing it will leave some seasoned XMPP developers scratching their heads for a while, till they find the source of the problem. 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.
- FreeFull 11y agoI have a feeling that USB's complexity is there for good reasons. As far as xmpp and css/js go, there definitely is a lot of complexity that could have been avoided with a different initial design, although hindsight is 20/20.
- deleted 11y ago[deleted]
- rprospero 11y agoWhile I'll join you in demanding the kids off our lawns, I'm looking forward to seeing 120V AC run through the very last serial port. There's nothing like sending a message down the serial power and seeing nothing come back. So many wonderful ways to fail. 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.
- anon4 11y agoProtocols are getting more complicated. Sometimes needlessly - XMPP; sometimes out of necessity - we can't let you poke bits in the framebuffer directly, because the graphics card is now this almost-blackbox superscalar coprocessor that only incidentally maybe has a display hooked to a tiny little region of memory that you could perhaps think of as a "framebuffer", but the framebuffer is actually not linear, but tiled in some weird way for performance. Actually making the complex and simple stuff coexist on the same system is a very... complicated challenge.
- colechristensen 11y agoSo here's a question (and a personal manifesto) 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.
- joepie91_ 11y agoMeh. None of these are claims I really see particularly often. The claims I do see are: 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.
- ape4 11y agoI agree that XML is only slightly more verbose than JSON but they should still make a JSON version of the spec or it will die. It should be pretty straight forward to mechanically change the XML into JSON.
- insertnickname 11y agoThey did: "XEP-0295: JSON Encodings for XMPP" https://xmpp.org/extensions/xep-0295.html https://xmpp.org/extensions/xep-0295.html :-)
- ape4 11y agoHow about that! Then they need to publicize it. Make a website, say, jmpp.org (pronounced "jump") and a reference implementation.
- davecridland 11y agoYou might want to read it. :-) The problem has mostly been that nobody's come up with a better JSON representation than one in a April 1st XEP (and they have been proposed - as ralphm says, they're mostly XML-with-curly-brackets, which makes them have the disadvantages of both). 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.
- ape4 11y agoOh yeah (about it being a joke). Thanks for the other pointers.
- sonnyp 11y ago> NOTICE: This document is Humorous. It MAY provide amusement but SHOULD NOT be taken seriously. EDIT: Also the X in XMPP stands for eXtensible not XML
- jacobolus 11y agoAs always, when making these kind of statements, the question is: relative to what, and for what purpose? Without knowing that, it’s quite hard to know what the author of this page is getting at. Who is he arguing against, and what’s the context for these “myths”? 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.
- slasaus 11y agoDon't forget Whisper Systems protocol used by TextSecure[1] which is based on Google's protobuf[2] and JSON in a REST api. [1] https://github.com/WhisperSystems/TextSecure-Server/wiki/API-Protocol#user-content-sending-messages https://github.com/WhisperSystems/TextSecure-Server/wiki/API... [2] https://developers.google.com/protocol-buffers/ https://developers.google.com/protocol-buffers/
- nickpsecurity 11y agoOne could get started with PSYC. It's open. http://about.psyc.eu/Introduction http://about.psyc.eu/Introduction
- Arathorn 11y agoThe wiki page was in response to the XMPP bit of http://matrix.org/blog/faq http://matrix.org/blog/faq. Coincidentally Matrix is a Wave-like protocol that hasn't been shoehorned into XMPP.
- legulere 11y agoThe advantage of JSON is that it's way easier to handle because it maps directly to structures that are available in every common programming language.
- davecridland 11y agoFWIW, I added the following to the Wiki page when I saw it was on HN, which might help give some context to what you're reading: 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.
- dhaneshnm 11y agoI find it strange that, nobody has mentioned MQTT so far in this discussion. Isn't MQTT also a 'competitor' for XMPP, besides JSON-over-Websockets? especially on mobile devices ?
- detaro 11y agoIt is not really a competitor for XMPP. It transports messages and you could build a chat service on top of it, so it is in a somewhat related space, but XMPP and MQTT aim at very different things.
- fbellag 11y agoI'm always playing around with messaging for pet projects, and tried xmpp a couple of times. 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?
- nickpsecurity 11y agoHere's an old critique of XMPP by author of PSYC protocol: http://about.psyc.eu/XMPP http://about.psyc.eu/XMPP I think it showed how its complexity vs value delivered tradeoff isnt so good. Decided against trying to implement the protocol.
- Zash 11y agoSo did you implement PSYC instead?
- nickpsecurity 11y agoNo. I already had a reliable communication system over UDP. I tweaked it with some stuff from PSYC and elsewhere. Let me achieve needed goals without doing a whole PSYC system. Had I needed full XMPP alternative I might have built PSYC just to see what would happen.
- davecridland 11y agoWorth noting that two of the people fairly heavily quoted on the shortcomings of XMPP both serve on the XMPP technical Council at the moment. (One of them is me, the other is Philipp Hancke).
- nickpsecurity 11y agoThat is interesting. My initial guess would be one of the two: (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?
- davecridland 11y agoActually a mixture. Some shortcomings have vanished because while they're problems, they're solved problems. And adoption etc, too. 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.
- lep 11y agoOfcourse if i (or anybody else) would write a chat protocol today i would make changes. But i'm not even sure if i would abandon xml. I'm in the same boat as you and think xml is too verbose and all that other stuff but i've recently programmed some xmpp projects and i came to the conclusion that xml actually realy does work well. And i didn't even use a library like sleekxmpp because i wanted to know everything. I'll just say: good luck designing something that'll be able to grow for 20 years and still work today. You can realy feel where the X in XMPP comes from. 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 https://github.com/louiz/biboumi [2]: https://github.com/siacs/HttpUploadComponent https://github.com/siacs/HttpUploadComponent
- jessaustin 11y agoFrom where I sit typing this, I can look out of my window and see Bryn Myrddin - Merlin's Hill - underneath which, legend says, Merlin lies asleep, awaiting a time when England in is peril once more. This is a problematic myth, since Bryn Myrddin isn't in England... "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.
- davecridland 11y agoThanks for picking up on the important content there. ;-) 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.