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

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Jeff,

Small world.

Jeff McAffer wrote:
> I have adapted Smack for Eclipse and built a relatively simple chat client.
> If you point me in the right place I would be happy to contribute my
> experiences.

This is the place.  I happen to be working on an ECF XMPP provider that 
uses Smack right now (honestly).  Please contribute your experiences 
directly to this list...and to me in email if you have code you are 
willing to share, etc.

> BTW, you should go back to the Smack guys with changes. They seem pretty
> active and helpful.  I'll be damned if I can figure out how to create a bug
> report for them though...

Yeah...Jive Software is here in Portland, and I've corresponded with 
Matt Tucker at Jive about the use of Smack API in ECF.  We have a 
request into the foundation to include smack bins in the ECF XMPP 
provider plugin.

So far, I've found Matt's email address to be the best bug reporting 
mechanism for Smack ;-).  But you didn't hear me say that publicly.

Jeff we're almost done with an XMPP provider and am in need of a simple 
Eclipse UI for demonstrating the functionality with in the Eclipse UI. 
Any chance your impl would provide a simple buddy list and chat UI that 
we could use in the short term?

Thanks!

Scott


> Jeff
>
> "Scott Lewis" <slewis@xxxxxxxxxxxxx> wrote in message
> news:4203FCE0.60901@xxxxxxxxxxxxxxxx
>
> > 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