sections.   propaganda :: about :: konstware :: writings :: resume :: photohunt :: ::
[24.03.03] Kharkov news
[22.03.03] Transilvanian realities
[21.03.03] Iasi-Chisinau operation IV
[21.03.03] blogs and Iraq
[03.01.03] the misterious Jabber creature
  [30.12.02] global worlds
[01.12.02] taste our balls
[28.11.02] the harm of charity
[12.11.02] Chisinau and its residents
[12.11.02] a major site update
  [ subscribe ]
[ archive .. ]
10 May 2001 :: I don't work for the NIX solutions company anymore. Decided to have a rest and pay some attention to finishing the university... [ more.. ]

03 Jun 2004 :: This time by recommendation of one lady who was going to Chisinau the same day, I decided to try out the train. As usual, I wanted to go by bus, but now I'm happy I didn't do that... [ more.. ]

15 Jun 2003 :: It was a time when every evening before falling asleep I used to ask myself on results of the day's activity. That's how I was saying (not in aloud, of course): "Konstantin, tell me sincerely, what have you done today? Have you become better, smarter, reacher, happier?"... [ more.. ]

[ 3rd Jan 2003 ] the misterious Jabber creature | 9 comments | leave a comment |

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, 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..

design and content, copyright © , 2001-2019 | ~ 3261 visits daily | statistics