[JDEV] Protocol plugins

Sun Jan 27 19:09:57 CST 2002

What you have described is more or less equivalent to a null client, a
daemon that acts like a Jabber server to the local host but as a client to
external IM systems (Jabber, of course, included). As we've been mentioning
this month, it is an important piece of technology that will need to be
filled in eventually. The trouble, of course, is that it's a lot of work,
since it requires user-friendly (and, more importantly, Windows-friendly)
Jabber server components, which we don't have. I'm hoping to implement some
of this in Jabber.NET, which has a pretty solid foundation so far, but
there is some standards and protocol work that we will need to get through
first.

-Mike

                      James Widman                                                                                                      
                      <j-widman at cornellc        To:       jdev at jabber.org                                                               
                      ollege.edu>               cc:                                                                                     
                      Sent by:                  Subject:  [JDEV] Protocol plugins                                                       
                      jdev-admin at jabber.                                                                                                
                      org                                                                                                               

                      01/27/2002 06:30                                                                                                  
                      PM                                                                                                                
                      Please respond to                                                                                                 
                      jdev                                                                                                              

This is inspired in large part by Gaim's plugin system.  I thought it
would be cool if jabber clients had something similar...let me know what
you all think.

[sorry for the length of this email...I don't really know how to make it
shorter...]

[I've searched the archives a few times for relevant terms; again, my
apologies if something like this has already been discussed]

    Transports are very useful because they simplify the design of
jabber clients; a client only has to know jabber protocol, and this is a
Good Thing, but it has some limitations. For one, inter-IM-system file
transfer:  do the server admins really want all that file traffic going
through a box that must already deal with thousands or tens of thousands
of users?  Probably not if they don't have to.
    End users may want to  have a direct connection with a foreign IM
system or users on that system, like in GAIM or Trillian.  Passwords are
another good reason to have oob (Out of Band) connections: We want our
passwords stored in one place (if any), dammit: on our Personal
Computers, not jabber servers.  I know one thing that keeps me from
inviting other people to use my jabber server is that their passwords
for other IM systems would be stored on my machine in plaintext.

    But!  We want to simplify client design, for one thing.  A client
shouldn't have to know how to talk to every IM system; just jabber
protocol, C-to-S.

    So now what?

    Well, what if there were a way to define an IM systems's protocol
(or any protocol for which we can make a transport, for that matter) in
XML?  Suppose a client sent something like:

<iq type="get" to="imsystem.somedomain.net">
    <query xmlsn="jabber:iq:protocol_plugin">
        <protocol name="non-jabber-protocol"/>
    </query>
</iq>

    The server would then respond with the protocol definition for the
non-jabber im system if it could supply one, and "error" otherwise.

    The jabber client would then be able to use this definition as a
plugin to communicate with that IM system just as GAIM does.  The
protocol definition for an IM system would ideally include definitions
for how chats, conferences, single messages, vCard-ish info transfers,
and file transfers should be conducted.

There are a lot of potentially nice things about this:

    - it takes some of the load off of the jabber server, especially if
we're going to do file transfers from one IM system to another.

    - any given protocol only has to be implemented once (probably in
XML) and then it can be imported and immediately "plugged in" by both
clients and transports...for this to work, the client only has to know
how to work with plugins in general (rather than being programmed to
know any single protocol) -- we might be able to use GAIM code for
leverage here.

    - no client is required to know how to import protocol plugins (but
the cooler ones will ;)

    - each protocol definition could be time-stamped, and the client
could have an option to automatically check for and download new
definitions, so that the end user doesn't have to be bugged with plugin
maintenance.

    - it gives jabber clients more potential for p2p functionality; i.e.
we don't have to go through specific servers to communicate, and
therefore we don't have to worry about whether those servers have gone
down in order to maintain communication or a file transfer.

    - it provides a graceful way around AOL's IP blocking. Jabber.org
can usefully run aim-t again, and end-users will have accounts on
jabber.org and access jabber.org's aim-t solely for the purpose of
getting the protocol plugin.  Registration and IMs no longer need to go
through a transport, but they still can; the intent is to only add
functionality and not to remove any.  Consequently, the friendly
neighborhood jabber server doesn't have to know users' passwords for
other IM systems.
    (Temas, I know you're against trying to get around AOL's blocks, but
my intent here is not to "stick it" to AOL; I was primarily thinking of
improving functionality for the end user, and maybe competing against
Trillian. If we want to avoid stepping on AOL's toes then we could just
opt not to release a protocol definition file for AIM; people would
probably still use GAIM and Trillian (and aim-t on their personal jabber
servers), but at least Jabber.org would be less associated with it.)

    - it might be possible to code and use only one good generic
transport that becomes a transport for a specific protocol when it loads
a protocol definition file, thus cutting down on the amount of transport
code to write/maintain.

    - Ideally, writing a new transport becomes equivalent to defining
the protocol in an XML-encoded file.

    And, of course, a lot of client developers will be pleased as punch
to implement (or, ideally, #include) a client side plugin system if it
means beating the snot out of Trillian when the next C|Net IM client
review comes around ;)

...So that's about it.   Any comments and/or criticism would be most
appreciated.

_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev