3 ms·
4: XMPP is many things, but it's definitely not simple or easy to implement. Start with the core spec, RFC 3920. Right away you'll run smack into the problem o
by jmillikin 13y ago
4: XMPP is many things, but it's definitely not simple or easy to implement.
Start with the core spec, RFC 3920. Right away you'll run smack into the problem of XML namespaces, which is a feature that every XML library pretends to support, but with a whole bunch of caveats. Before you can do so much as initiate a session, you will need to search the universe of XML libraries for one that implements a full parser and has good namespace support.
(When I wrote an XMPP library, I ended up using libxml2 because the only platform I care about is Linux.)
Next you'll have to implement encryption (TLS) and authentication (SASL). As with all security-related code, this part of your application is terribly easy to fuck up in a non-obvious-but-user-endangering way. Does your TLS library check that the certificate is valid? Many don't by default. Does your SASL library implement the spec correctly? SASL is complicated and difficult to test, so it's easy for even experienced developers to break authentication for some subset of users.
(I used gnutls and gsasl to do most of the heavy lifting, but still ran into many problems. For example, my library doesn't work with some versions of ejabberd because ejabberd's implementation of SCRAM-SHA-1 was broken: https://support.process-one.net/browse/EJAB-1632 https://support.process-one.net/browse/EJAB-1632).
OK, so you've found a full-featured XML library, you've figured out TLS and SASL, and you can send "hello world!" to another account. Think you're done? Hahaha, no my friend, you're just getting started.
To do anything interesting with XMPP, you need to implement XMPP extensions (XEPs). There are currently three hundred and twenty seven XEPs, indexed at http://xmpp.org/xmpp-protocols/xmpp-extensions/ http://xmpp.org/xmpp-protocols/xmpp-extensions/ , and many of them are at least as large as the core spec itself. XEPs cover such important functionality as multi-user messaging, file transfer, voice/video chat, full encryption, avatars, and away messages.
(I decided to skip all that, not do any XEPs at all, and limit my library to simple one-on-one chats because that's all I needed it for. If you're writing something for use by customers, you will not have that luxury.)
And of course, it's all implemented in XML. Hope you've got a sturdy keyboard.
- scotchmi_st 13y agoYeah I would certainly say that building a messaging system of any type with the features of XMPP /from scratch/ would be hard. Then again, just compare the config files of sendmail and exim to prosody or ejabberd. Given that tools for working with xmpp already exist, it does seem a shame to me that it hasn't seen wider adoption. Wasn't Google Wave based on it?
- Zash 13y agoFYI: RFC 3920 was obsoleted by RFC6120 in 2011. Implementing a lot of features is a lot of work. How is this different from any other protocol, or any kind of system?
- joeyh 13y agoI also love that, to connect to a XMPP server, a client needs to use SRV. Which AFAIK cannot be queried via gethostbyname, getaddrinfo, or any other standard interface. So you need to pull in a nonstandard resolver library, or to fork off `host`. With that said, John I'm very happy to report that thanks to your library I've been developing an XMPP client for months and have yet to even see any XML.
- claudius 13y agoRequiring SRV essentially allows things like hosted.im to work – using a SRV record for a specific subdomain is probably better than putting in new record types for every protocol cropping up (cf. MX). The fact that SRV records cannot be queried using standard libraries is likely more of a deficiency in the libraries rather than the protocol. That said, thanks a lot for git-annex & the assistant =)