More permanent stuff at

12 August 2005

Clients, Servers and XML

I have been programming professionally, full-time for five years now. So clearly, I am still figuring things out.

Well, here is another one...

Simple XML protocols for client-server suck. They are overkill. Maybe on a large project where messages are big and complicated, they make sense--but I have never come across one of these. For simple client-server applications where messages are short and/or unstructured (5-10 parts), byte oriented messages still rule.

Here is why: Tagfriendly Tagfriendly has a client and server that must communicate with each other. The faster messages are read and acted upon, the better. When I was using XML (back with servlets), I had a complex scheme of reading all the XML into a structure, "tasting" the XML to decide what kind of message it was, then a factory to create the message. With a byte-oriented protocol, this is much simpler. The first 4 bytes of the message encode an integer that specifies the message type. From there I can go to the factory to create the message.

The fact that the XML parsers that come with Suns JAVA SDK are somewhat feature-rich (slower, more code, etc.) was not helping my previous situation.

So I am happier now. There are some other benefits to this approach: When I eventually write plugins for iTunes that communicate directly with the Tagfriendly server, I will not have to fiddle around learning the different ways for parsing XML for Microsoft and Apple. All I have to do is remember the structured format of my own messages. And if I cannot do that already, I have no business being here.

My next entry will be a few observations I made duing my transition away from servlets.