On Thursday, August 30, 2001, at 01:22 PM, Dave Smith wrote:

> On Thu, Aug 30, 2001 at 08:04:35PM +0000, webmaster@... wrote:
>> A new message was posted:
>>
>> Address: http://www.xmlrpc.com/discuss/msgReader$1982
>>
>> By: Lennon Day-Reynolds (lennon@...)
>>
>>
>>
>> It seems like there are a couple of issues here: one, we want to
>> eliminate as much of the overhead of HTTP transactions as possible,
>> and two, we want to establish some sort of consistent naming or
>> location standard so that local resources can discover each other.
>
> Admittedly, I'm a biased party -- however, I belive that if you look at
> Jabber it solves the majority of the issues which are discussed here:
> addressing, routing, HTTP overhead.. :) Something to consider..
>

You know, after reading the docs on jabber.org, I was all fired up to
give it a shot...and then I tried to compile the server daemon on OS-X.
That failed, but after some rooting around on Google, I was able to find
a source tarball that had been hand-groomed to work on OS X -- still no
luck. Finally, after about two hours of fiddling with the pthread
library makefiles, trying totally static builds (to avoid dynamic loader
issues), etc., etc., I had to give up and go back to something more
productive. (The unwritten subtext here is: if anyone *has* been able to
get the voodoo working enough to get a binary for jabberd on OS-X, I'd
love to have a copy).

Now, I'm stuck trying to make a choice: if I stick to vanilla XML-RPC
over HTTP, I have stable, simple libraries to work with in my language
of choice (Python), but I'll have to recreate a lot of the routing,
presence, and query processing logic that Jabber provides. On the other
hand, if I keep plugging away on Jabber, (possibly event digging my old
Linux box out of the closet where it has languished since the G4
PowerBook arrived) I'm working in much more uncharted territory so far
as support libraries are concerned.

Looking through the Jabber protocol and extensions, though, I'm struck
over and over again by the difference in basic approaches used for
request processing between HTTP, XML-RPC, and Jabber. In HTTP,
everything's simply accessed by URL. XML-RPC adds a fixed, explicit
serialization method for structured data passed to and from those
locations. Finally, Jabber (like SOAP) supports arbitrary data to be
encoded in each request and response, and relies on the server and
client to use a different XML namespace for each request type.

There's an interesting progression here:
HTTP: data as unstructured chunks of text or name/value pairs
XML-RPC: data as arbitrary collections of a fixed set of primitive
data types
Jabber/SOAP: data as objects, with arbitrary attributes,
relationships, and namespace isolation

I have to admit that I'm really starting to like the Jabber approach, if
only for the fact that it dropped all the cruft of pre-XML protocol
handling, shed the illusion that it was a document publishing
architecture, and went for a lean, fast core that could easily be
extended with new message types and operations.

Okay, I'm done rambling now...time to get back to some actual coding...

Lennon Day-Reynolds