Home » Archived » Eclipse Communications Framework (ECF) » XMPP Implementation
| XMPP Implementation [message #579418] |
Fri, 04 February 2005 19:50  |
Eclipse User |
|
|
|
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  |
 Scott Lewis
Messages: 1038
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 |
Jeff McAffer
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 |
Scott Lewis
Messages: 1038
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
>>>
>>>
>
>
>
|
|
|
| |
  |
Goto Forum:
Current Time: Wed Apr 24 17:48:39 GMT 2024
Powered by FUDForum. Page generated in 0.02846 seconds |
] 
Search
Help
Register
Login
Home
