Re: [DotGNU]To What Degree Jabber?

[Adam Theo]

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: http://www.theoretic.com
//  ||  \\     "Bringing Ideas Together"
    ||      Jabber Protocol: http://www.jabber.org
    ||         "The Coolest IM on the Planet"
    ||  "A Free-Market Socialist Patriotic American
    ||      Buddhist Political Philosopher."