Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » XMPP Implementation
XMPP Implementation [message #579418] Fri, 04 February 2005 19:50 Go to next message
Eclipse UserFriend
Originally posted by: ddura.macromedia.com

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.

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.

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?

Not sure if this makes much sence, feel free to ask questions.

Thanks

- Danny
Re: XMPP Implementation [message #579440 is a reply to message #579418] Fri, 04 February 2005 22:53 Go to previous messageGo to next message
Scott Lewis is currently online Scott LewisFriend
Messages: 971
Registered: July 2009
Senior Member
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
>
>
Re: XMPP Implementation [message #579601 is a reply to message #579440] Tue, 15 February 2005 05:09 Go to previous messageGo to next message
Jeff McAffer is currently offline Jeff McAfferFriend
Messages: 104
Registered: July 2009
Senior Member
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.

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...

Jeff

"Scott Lewis" <slewis@composent.com> wrote in message
news:4203FCE0.60901@composent.com...
> 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
> >
> >
Re: XMPP Implementation [message #579617 is a reply to message #579601] Tue, 15 February 2005 06:32 Go to previous message
Scott Lewis is currently online Scott LewisFriend
Messages: 971
Registered: July 2009
Senior Member
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@composent.com> wrote in message
> news:4203FCE0.60901@composent.com...
>
>>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
>>>
>>>
>
>
>
Previous Topic:some small patch ...
Next Topic:Relationship to KOI technology project ?
Goto Forum:
  


Current Time: Sat Nov 22 21:44:10 GMT 2014

Powered by FUDForum. Page generated in 0.01571 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software