News for hackers. Stuff that matters.
Re:Facebook Messenger protocol in Pidgin by rakoo on Thursday January 14, 2016 @08:54AM (#10901346)
There are multiple pain points with the way the XMPP protocol is "organized":

* It's designed to accommodate as many use-cases as possible with a variety of actors chiming in with their own requirements

* a tiny core that doesn't do a lot, and a gazillion extensions

* when you want to implement a software in XMPP world, you don't have a clear view on what extensions you need to implement and what extensions are nice-to-have (other than word of mouth)

* corollary: extensions can move fast, some are new, some die, but the perception doesn't change as fast, so old habits remain for a long time (cue "PSYC said XMPP sucks") and softwares don't evolve to accommodate later improvements

* second corollary: since the bulk of what makes XMPP useful is defined in extensions, as a user you don't know which client or which server you should pick

* by design there's no reference implementation, which means you don't really know where to start

* it's XML, and XML doesn't exactly play well with recent languages (you won't write XML itself so you'll use what your language gives you, but it doesn't always map very well with XML)

To summarize, XMPP can do everything, provided that you know your way. If you don't know anything you will most likely be disappointed by your first experience, as a user.

Re:Facebook Messenger protocol in Pidgin by greggman on Thursday January 14, 2016 @10:53AM (#10902095)
Does xmpp handle the case where you've read a message on another client and you want all clients to see it as read? Seems like possibly an argument for centralized storage
Re:Facebook Messenger protocol in Pidgin by finnn on Thursday January 14, 2016 @11:23AM (#10902296)
Re:Facebook Messenger protocol in Pidgin by ape4 on Thursday January 14, 2016 @12:41PM (#10902908)
I hope we can craft a better protocol. One that people will love to implement.
Re:Facebook Messenger protocol in Pidgin by rakoo on Thursday January 14, 2016 @03:36PM (#10904266)
At this point I don't think there is a huge benefit in starting another protocol. There are problems with XMPP, but IMHO they're more in how it is organized than in the protocol itself. XMPP has surveyed a huge chunk of the space, it has seen where things are difficult and proposed a solution for that. It is in use by many entities already, with many different use cases (one of the later extensions (https://xmpp.org/extensions/xep-0365.html) is to use XMPP over radios with atrocious conditions: latency in minutes, throughput as low as 75 bits/s. Also, for some reason XMPP has seen some success in military), it has all the benefits of being an approved IETF protocol (one of which being that it will still be here in 10 years, whatever happens). Sure, it's old stinky XML, but it's not like it's a brand new technology where little documentation exists. There are libraries in most languages already.

What we really lack is a bit more guidance: the XSF (XMPP Standards Foundation) is only interested in making sure the standard is properly specified, that demands are met appropriately. It's a huge huge job, but for a community of developer it's not enough. There has already been talks to update the suite of extensions that are considered almost-mandatory in a modern IM software; it would also be really awesome to have a reference implementation for each usage (ie one server, one IM client, one VoIP client, one microblogging client, ...) because, like many others, I find tangible code we all agree on to be of very high value.

I fear that other protocols will be created, they will all (or at least a good part) die, and in the end we'll have XMPP, standing there in the waves of protocols, chugging along quietly. People will be mocking it not because it doesn't work, but because they don't understand it (and that will be a fault with XMPP, not with people, because it will remain extremely complex)