If you try to work IRC up to be a real, true XMPP replacement, you'll be complaining about how hard it sucks in no time. (Also part of the reason it's not a replacement, real users want that state.) This is fine, too, I don't have a problem with IRC for what it is, but you can't just drop it in everywhere you see an XMPP server. IRC clients are actually just as quirky, IRC just doesn't hang on to anywhere near as much state or you'd see it mangled, spindled, and mutilated too. Again, I know it's not perfect but in the space of "deployed IM protocols" it does not make a bad showing. XMPP actually managed to avoid a lot of problems that even the "professional" systems had, having learned from their experiences AIM last I knew still had some encoding corner cases you wouldn't expect in a modern program, all of the protocols had major encoding growing pains, surprising versioning issues, all these little quirks inside them that you never noticed because you can paper over a lot when you control both the clients and the servers.
XMPP actually dealt with these semi-magical roster entries just fine, to my surprise.) Those specifications really matter and just sort of bashing some stuff out that's 90% correct most of the time isn't good enough when you're trying to communicate with so many different systems. Well beyond the stock ejabberd shared rosters, but pretty custom to our environment. (Corporate customers don't "get" rosters, don't get that you can start with a blank roster and work your way up, so I added a module to build rosters based on grouping criteria specified by the user and driven by outside input. (Though the transport protocol is one of the spottier bits of the protocol.) The core bits of XMPP are generally reasonably well specified and in my experience actually held up surprisingly well as I bent and spindled it a little bit. That's where your roster problems come from, it's where a not insignificant number of your transport problems come from too. If XMPP taught me anything, it is that it doesn't matter how many specs you throw at a programmer, they're just going to bash on the program until it sort of works most of the time and release it. The problem is getting the standardized semantics. I could transform the entire XMPP protocol stack into JSON in a week, with implementation in ejabberd and one of my clients. The XML was always the easy part, even if JSON would have been even easier. I spent much more time working on semantic issues than I ever did working on the raw XML, orders of magnitude difference. None of the "professional" protocols seem to be significantly simpler, because they can't be. IRC isn't a replacement for what it does, and yeah, the problems come from the problem domain, not the protocol.
Ejabberd sucks professional#
I have implemented two clients, a generalized libpurple transport, and spent significant time on a server in a professional environment for sale to real customers. This is what the XMPP author should have done in first place. It wouldn't take much fix the warts on IRC and extend it to cover everything that XMPP tries to do. A protocol that, despite an immense range of features, can easily be typed by a human on a telnet prompt, in real time. Take a lesson from IRC, a group-chat protocol that, despite its age, works and scales amazingly well. Most people do not realize how much of the messiness comes from the problem and not the protocol. XMPP makes it seem like a much harder problem than it really is, but only because XMPP is broken beyond repair. Neither is semi-decentralized instant messaging. However, instant messaging is not rocket science.
And don't get me started on "Transports". Some clients would even manage to unsubscribe existing contacts for inexplicable reasons. There was a time when my roster would get screwed up in new, random, interesting ways whenever I launched a different client. It leads to a client/server ecosystem where each implementation speaks a different dialect because it's nearly impossible to get the protocol right. It leads to ridiculous overengineering through layered complexity. XMPP is what I cite when I try to explain the "XML mindset". It has never seen serious adoption because nobody wants to touch it - and for good reasons. You only begin to realize the magnitude of the failure once you try to implement a client, and most people don't do that. No, it is actually worse than most people realize. XMPP is much better than most people realize, anyhow.
0 kommentar(er)
