[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: 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."
- Re: [CoreTeam]Re: [DotGNU]To What Degree Jabber?, (continued)
- Re: [DotGNU]To What Degree Jabber?, Richard Stallman, 2002/04/12
- Re: [DotGNU]To What Degree Jabber?, Bradley M. Kuhn, 2002/04/12
- Re: [DotGNU]To What Degree Jabber?, David Sugar, 2002/04/12
- Re: [DotGNU]To What Degree Jabber?, Gopal.V, 2002/04/13
- Re: [CoreTeam]Re: [DotGNU]To What Degree Jabber?, Barry Fitzgerald, 2002/04/13
- Re: [DotGNU]To What Degree Jabber?, Chris Smith, 2002/04/15
- Re: [DotGNU]To What Degree Jabber?, Peter Saint-Andre, 2002/04/15
- Re: [DotGNU]To What Degree Jabber?,
Adam Theo <=
- Re: [DotGNU]To What Degree Jabber?, James Michael DuPont, 2002/04/17
- Re: [DotGNU]To What Degree Jabber?, Peter Saint-Andre, 2002/04/17
- Re: [DotGNU]To What Degree Jabber?, Peter Saint-Andre, 2002/04/13
Re: [DotGNU]To What Degree Jabber?, Norbert Bollow, 2002/04/11
[DotGNU]Just Some Comments/Analysis, Seth Johnson, 2002/04/18
[DotGNU]To What Degree Jabber?, Peter Saint-Andre, 2002/04/12