[news.eclipse.technology.ecf] Re: XMPP Implementation

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Daniel,

Daniel Dura wrote:
> Hello,
>
> Very interesting project. I am trying to wrap my head around the 
> architecture, and hopefully someone can answer a few questions for me. I am 
> considering this in the realm of integrating with an XMPP server and how the 
> Shared Object metaphor will work when the XMPP implementation is complete.

Yes.  Actually, we have already begun building an XMPP provider for 
ECF...but not yet completed it/tested it fully.  Perhaps we can work 
with you/others from the dev community on this?

> I would assume that an ISharedObjectContainer would be the server I am 
> connecting to. So for example, it would be myserver.com, and the 
> authentication would be handled by the container and any arguments I pass 
> into it.

Yes.  With our provider implementation, the ISharedObjectContainer 
instance is a very thin 'wrapper' for communication with an XMPP server. 
 We're using the Jive Smack library to implement this container.

The ISharedObjectContainer.joinGroup semantics is mapped onto the XMPP 
'connect to XMPP server and authenticate'.

> Where I get a little confused is what defines a SharedObject in regards to 
> the XMPP situation. Lets say I wanted to build a basic chat client (buddy 
> lists, chat, group chat, etc.). If I wanted to start a chat thread with a 
> user on my roster, it would make sence to create a SharedObject for that 
> thread. But how does a roster (buddy list) and all the presence messages 
> associated with such, work? Would I create a roster shared object? Would 
> that shared object give me presence related message events?

There are other ways to design this, but we have (so far) taken the 
approach of having a shared object that handles 'presence/roster and IQ' 
messsages specifically, decodes those messages and then communicates the 
implied user interface state change to a user interface for representing 
 user presence (...also potentially to multiple client-provided user 
interfaces for presenting such information...we've not yet finished this 
part of the ECF UI architecture).

So our approach is currently:  implement handlers for the various xmpp 
protocol messages as 1 or more XMPP-provider-implemented shared objects, 
and then put logic into these shared objects to interpret the various 
messages, extract the relevant data in the messages, and then have them 
delegate UI state changes to either a) other/additional shared objects; 
b) directly to user interface code.

LMK if you would like to work directly with the team on producing this 
XMPP provider and the shared object implementations.  Although we have 
the basics in place, this is one of several areas that we would like to 
complete work already started and are trying to balance that against 
other priorities.

Thanks,

Scott



> Not sure if this makes much sence, feel free to ask questions.
>
> Thanks
>
> - Danny