[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]To What Degree Jabber?

From: Adam Theo
Subject: Re: [DotGNU]To What Degree Jabber?
Date: Tue, 16 Apr 2002 16:11:12 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.9) Gecko/20020313

Just wanted to clarify some things I've seen over the weekend, but not
had the opportunity to respond to until now.

Jabber is not an encapsulation mechanism like SOAP or XML-RPC. It is a transport protocol like HTTP or SMTP. Jabber can be used to route SOAP or XML-RPC (or any other XML, for that matter) to any Jabber-aware application. By Jabber-aware,k I mean the application somehow logs into a Jabber account and listens for messages being sent to it, like how a e-mail client logs into a POP3 account and receives e-mail. Except unlike e-mail, the Jabber-aware application doesn't have to display the Jabber packet to the user in any way. Since the Jabber packet is XML using namespaces, it can be programmed to "understand" certain messages, and re-act to them accordingly. Trying to say you can't have both is like trying to say you can't have an orange peel *and* the orange.

Jabber currently is getting very good at transmitting XML-RPC. As of this weekend there are now two Perl libraries for doing this sort of thing very easily (Jabber::RPC and Net::Jabber). C and Java libraries would not be difficult. Jabber does not yet have a finalized way of doing SOAP, but that is coming very soon.

I just want to correct some people. It's no big deal, but there is nothing called "jabber:middleware". What I assume is meant by that is called "Jabber As Middleware" (or "JAM") in the Jabber world. And JAM is no different than "Jabber As IM". They are the exact same protocols, just used for different things. Exactly like how HTTP is still the same HTTP whether it's being used to transmit web (HTML) pages or exchange backend RPC calls between components. There is no difference in the protocol, just the usage.

A Jabber client could just be a very simple perl script (or whatever else you like) that receives the incoming Jabber messages, "reads" them, converts them to various other formats depending on the context, and then forwards them on to other applications, even locally. So you could build a Jabber-aware frontend for your favorite email reader. Then this frontend would receive Jabber messages, translate them into email format (mbox or whatever), and deposit them in your email reader's folder. You would then be able to read (and even reply if you built code for the reverse direction) Jabber messages just like email.

Jabber is not good at transferring binary data, but is great for transferring XML or plain text data. I would suggest using Jabber as the main protocol to transmit text-based data as well as set up sessions, manage presence, publish and subscribe to components, and many other "meta" functions. Then create some agents for HTTP or FTP for the binary transfer and have Jabber command them to do the various binary-specific functions.

Jabber can help with search and discovery. This is an area that Jabber is limited in right now, but everyone in the Jabber community wants to fix that. Many have been actively putting their greymatter to use trying to solve this, and expect excellent solutions in the coming months, especially if people from DotGNU could help out in creating a generic and powerful search & discovery system for Jabber.

Jabber also does queueing of messages, if I'm not mistaken. Not sure what was ment by this by the person who asked, but Jabber messages are queued if the user is offline, and sent to them when they come back online. All queueing is done by the recipient's server, not the sender. This would be a simple client-side patch, though, if you want to change it. So, if the recipient's server was offline, then the message would not queue, and the sender would instantly get an error.

If you know of a Jabber server, you can "browse" to it and get a list of all its functionality and installed components. There is also a crude search & discovery for individual Jabber users called "Jabber User Directory" (or "JUD"), which could be easily adapted to list servers instead, to create a search & discovery for them.

I'm eagerly awaiting Norbert's decision. I hope it'll say Jabber becomes the default and preferred (but not exclusive, of course!) transport protocol for DotGNU communication. Not just between different DotGNU clients and servers, as well as server to server or client to client, but also inter-communications between components and agents of the same server distributed accross a network. Remember: Jabber is a transport, not an encapsulation model. Jabber doesn't replace SOAP, it transfers it.

    /\  Adam Theo, Age 22, Tallahassee FL USA
   //\\   Email & Jabber: address@hidden
  //  \\  (Boycotting AOL, therefore no AIM or ICQ)
=//====\\=  Theoretic Solutions:
//  ||  \\     "Bringing Ideas Together"
    ||      Jabber Protocol:
    ||         "The Coolest IM on the Planet"
    ||  "A Free-Market Socialist Patriotic American
    ||      Buddhist Political Philosopher."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]