Today we'll talk about my favourite hobby - instant messaging protocols.
During the last month I spent quite a lot of time adding to centericq. It is the thing I've been calling
the standard of internet paging of the future. I mean Jabber. Before I
started dealing more closely with it, I knew only two major ideas lying
at the base of it: full openness and wide use of XML. The first one
looked very nice to me, and it's not difficult to understand, as a
developer of client-side software -- especially after the problems I've
had with the popular, but closed type services. Among them there are all
the major players of the modern IM: ICQ, MSN and Yahoo!, so existance of
the full documentation and of several client and server side (sic!)
programs with open source code, looks like a miracle. There is no need
to play cat-and-mouse with developers. Such things used to happen not
only once with Yahoo! and ICQ, when one day all the previous
implementations started to have some unexpected effects. The guys just
came to work in the morning being upset with a hangover, and replaced
the sever with something that does the same things, but in a bit
"different" way. Sometimes the goals achieved with the help of such
stuff were more material. For example, about a year ago the ICQ protocol
started to work "poorly", the client software for it couldn't yet show
ad banners.
If I have already mentioned my favourite creation, before I get to
Jabber, I'll make a small digression. To my great pleasure, recently on
the Internet I found another application based on centericq. People are using, with full steam, a
feature to run external programs on receiving various events. The IMPSWAN
(Instant Message Publishing System Without A Name) site is a solution
used to publish notes by sending them to a special ICQ contact.
Everything's simple. Let's say, you're travelling and you feel like
writing something for a site (damn blogging). Let's say it's a travel
note. So, you go to an Internet cafe (or connect to the net in another
more exotic way), run ICQ and send your masterpiece to the service's
UIN. The rest IMPSWAN will do for you. It will save the note in a file
and then will upload it to the ftp server specified by you during the
registration.
Now, Jabber. The usefulness of using the XML seemed doubtful to me from
the beginning. I thought it was aimed to add a note of modernity to the
sound of the standard in order to attract more interest to the project.
Indeed, to send or to receive a text message, it's enough just to send
information about identifying the sender, plus the message itself. To
keep the protocol logically entire, especially if it's based on
streaming TCP connections, the lengths of both fields are included. In
this case, using a progressive format of data representation like XML
seems like too much: because of the tags a packet grows, and the client
swells because of the need to embed a minimal parsing routine.
On the other hand, the experience of other developers, and first of all
those of ICQ, whose protocol number has already reached 8, demonstrates
that as the process of developing and features adding goes, there is a
need to transfer a lot of various information. A lot of new packets with
their own formats appear: to send a message, a link, contacts, a user
information request, to update your own info, to search for contacts,
and tons of other stuff. The flexibility of such formats can be compared
to a steel rail: if you've forgotten to introduce a parameter from the
very beginning, it can be a real pain in the ass to get it into the
packet afterwards.
Among the advantages the using of XML in this context, there is, for
example, the possibility to add your own fields that only your client on
the other side will be able to process, along with the guarantee that
they will arrive to him. Finally, the XML is readable. It's much easier
to understand what you've done incorrectly in Jabber, than to try to
read a hex-dump of an ICQ packet, looking with one eye in the unofficial spec.
The possiblity to become cross-eyed is very high in this situation. But
it's much more simple with XML: here is a tag, here is an attribute one,
two, three, and over there is the data.
The standard of the protocol is described with several base documents plus the
set of JEPs (Jabber
Enhancement Proposition). The wind is milled minimally in them, mostly
they're very informative. It's also nice that there are examples of XML
packets demonstrating usage of a specific protocol feature.
By the number features it brings, Jabber, in my humble opinion, has
already surpassed ICQ, MSN and Yahoo!. Among the tasty things there are
advanced multi-user chat participants, who also have roles assigned to
them (owner, admin and user), this make its conferencing concept more
appropriate to the idea of IRC. It's also possible to connect so called
agents to the server. They are custom plug-in modules that can be
utilized by a server's users. It's possible to make requests to them as
well as to register information about the users. The parameter list for
each operation is defined "on fly". This way, for example, the user
search and MSN gateway features are implemented. Other than that, the
developers are simple and nice guys, thus their default central server
supports secure SSL connections.
The flexbility of the server side allows them to make the sweet dream of
the majority of the corporate users come true. I remember, because of
the stability of connection with the "external" world which left more to
be desired, in the offices in Ukraine where I used to work, we wanted
very much to have a "transparent" ICQ server which in the conditions of
a network being down would still allow sending and receiving messages
between the users in LAN. With Jabber it's very easy. You just have to
install a server at your location, and it would connect to other servers
to talk to other users when needed, including the "main" one,
jabber.com. When the outside world is accessible, contacts from there
are shown on-line. Otherwise, it would only be possible to talk to local
users. However, when a network goes down, the client program unlike the
one for ICQ, won't be suffering convulsions trying to connect to the
temporary unaccessible main server.
"But what is the disadvantage of the darn stuff?" - you will ask me.
Good question. With such an excellent part of the server it can be the
only thing - the clients. In order to test the Jabber module in
centericq in interaction with something presumably working, I tried all
the respective programs listed at freshmeat. For about a day I had been
knocking my head against the walls of non-compiling code. Finally, after
several strokes made with an axe, I did manage to install konverse. And a bit
later I discovered psi. Frankly speaking, the main
pushing force which made me implement the stuff in centericq was a great
amount of disperate ones who with a undisguised hope kept on asking if
it was planned, for they couldn't live anymore with a decent console
based client software. Like, there is already jabberx around with the
look and feel of ircII, but the soul desires something nicer.
The reason for such a slow evolution of the client part consists in the
fact that the Jabber team guys from the very beginning and till now have
been concentrating on the technical issues, not on the end-user who,
excuse my French, doesn't give a shit about the beauty of using XML in
the protocol and specifications being open. And of course they just
cannot compete with AOL/ICQ with their promotions a-la "ask Britney
Spears a questoin".
Nevertheless, such an approach is not that bad, since a technically
considered protocol in the long shot perspective is a priory doomed to
success. Like I said before, already there are 1,001 reasons for various
corporative bastards to install a jabber server on their own. Slowly,
quietly, and you will see that the standard will dominate the IM world.
All right, neither tomorrow nor next year..
::
