[Top][All Lists]

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

[DotGNU]Re: Why DotGNU should use Jabber

From: Adam Theo
Subject: [DotGNU]Re: Why DotGNU should use Jabber
Date: 01 Apr 2002 15:23:07 -0500

S11001001 <address@hidden> wrote:
> <speaking from="SEE Standpoint">
> I am looking at Jabber as a way to manage:
> 1. communication between SEEs
> 2. communication between SEE and language plugins
> 3. communication between user (`seerun') and SEE (invocation, etc)
> So, I must ask, where is jabber:middleware as of now? And how can SEE 
> use Jabber? Also, I should ask everyone, exactly what is needed from 
> IPC in this case?
> </speaking>

As long as the data to be transferred between SEEs and SEE components is
not binary, it can be sent over the Jabber network wrapped in Jabber
packets to Jabber addresses. Specialized Jabber clients (specialized to
do and receive only certain packets and data and ignore everything
else... "thin clients", basically) could be integrated into the SEE and
SEE components, or be a separate application that the SEEs use. This
would allow each SEE and SEE component to communicate with each other
"instantly" anywhere over the Jabber netork. SEE components would not
even have to be on the same machine, I would assume. They could be
spread out anyhere on the Internet.

Now, if the data was binary, Jabber could still help by doing the
metadata associated with that binary data, such as sending/receiving the
searches and queries, setting up sessions, negotiating agreements and
privacy contracts, etc... Jabber cannot do the binary itself due to a
flaw in XML itself, not Jabber.

Jabber can do all of the things you list above, as long as it's text, of

Jabber's addressing is powerful, too. It is similar to e-mail, with
address@hidden, but adds a third element, the /resource, for
address@hidden/resource. Host is the server or naming service the User is
under. Not all Jabber components have to have a Usrer. They can be a
Host, like for the AIM Transport for Jabber on my
server, for example. I register and interact with the AIM Transport
directly, and this Transport forwards my messages on to the intended AIM
user, which looks like address@hidden to me. Resources are
"sub-accounts" under the User. Resources use the same username and
password as the main account, but this means the user can log in
multiple times simultaneously for different purposes. For example, my IM
client logs in as "address@hidden/desktop", whereas my headline news
viewer can log in as "address@hidden/news". Services send to
specific resources, so my IM client will not accidentally get XML
intended for my news viewer.

So different components of the same user could log in as different
resources, and could be anywhere on the Internet. different SEEs could
be logged in as different users, etc....

As for Jabber Middleware's status. It's all there as for the protocol.
It's just a matter of making code to use the protocol to do the things
you want. There are a good number of GPL'ed tools out there already, you
could probably find a few to start from.

Hope this helps.

    /\  Adam Theo, Age 22, Tallahassee FL USA
   //\\   Email & Jabber: address@hidden
  //  \\    MSN: address@hidden   YIM: adamtheo2
=//====\\=  (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"

reply via email to

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