Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Eclipse Communications Framework (ECF) » Presence API refactoring and improvement
Presence API refactoring and improvement [message #609993] Fri, 29 December 2006 18:51 Go to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Folks,

Just to let everyone know, I've recently been making some significant
improvements to the presence API:

1) Refactored things to have a chat manager
(org.eclipse.presence.im.IChatManager) that manages the
sending/receiving of chat messages. This moves a number of things out
of IPresenceContainerAdapter directly, and puts them in the
IChatManager. I've marked all deprecated methods, interfaces, and
classes as @deprecated. I haven't removed them yet, as the old
rosterview depends upon them (and we probably want to continue to use
that UI for a short while as we create a new roster view, chat
input/output, etc. See the IPresenceContainerAdapter.getChatManager()
and org.eclipse.ecf.im.IChatManager interface (in CVS for latest).

2) Add several nice features to presence API for UI:

a) Delivery of buddy pictures. See
org.eclipse.ecf.presence.IPresence.getPictureData(). This will
interoperate with the Google Talk (and other client's) delivery of
little pictures for the roster list (the xmpp spec says png or jpg).
All we need to do to have this happen is put a user interface together
that shows the images when received.

b) Sending/receiving of 'user is typing' messages. Strangely XMPP
doesn't seem to have the notion of sending a 'user is now typing'
message. But I added interfaces for sending and receiving such messages
via IChatManager.getTypingSender() and ITypingMessageEvent (delivered to
message listener). This is implemented in the ECF XMPP provider via the
ECF shared object API...meaning that although it won't interoperate with
other XMPP clients (since those clients don't send such messages), for
two ECF clients they will send/receive 'user is typing' messages (even
if using external servers like google's!).

c) Sending/receiving of xhtml for messages (rather than just plain
text). This allows *a lot* of UI formatting to occur for chat
messages...and although I'm not an expert in JFace text display widgets
I would imagine that it allows the rendering of html-formatted text very
easily. This will interoperate with other XMPP clients (e.g. google
talk, gaim, etc.) as this uses the XMPP xhtml extension. So, all the
formatting done by these clients (e.g. font handling, links, etc) will
be made available to any new ECF chat UI work. See the
org.eclipse.ecf.presence.im.IXHTMLChatMessageEvent (delivered to an
IIMMessageListener).

3) I refactored the xmpp provider plugin (org.eclipse.ecf.provider.xmpp)
so the code is much more understandable (i.e. interfaces and classes in
org.eclipse.ecf.provider.xmpp) and better organized. Also all the
packages are now internal, so not considered API.

Along with items on http://www.eclipse.org/ecf/plan.php (please take
some of these on if you can)....there is more work planned: With the
shared object API underneath, I can easily introduce any ECF client <->
ECF client protocol desired...e.g. for sending/receiving user info
(email/other info) and/or Mylar context objects (so that, for example,
buddies could be informed via presence state/roster list change messages
when my active task changes).

Thanks,

Scott
Re: Presence API refactoring and improvement [message #609996 is a reply to message #609993] Fri, 12 January 2007 17:05 Go to previous messageGo to next message
Bill Joy is currently offline Bill JoyFriend
Messages: 60
Registered: July 2009
Member
Scott, I see from the provided link that you are planning on persisting
buddy information and that other Eclipse plugins (such as Mylar) will want
to use that roster to select a buddy then initiate some sort of object
transfer.

Is it going to be possible to contribute to that roster dynamically?

For instance, I am using JmDNS (as encapsulated by ECF) to discover peers
dynamically and so for me no roster needs to be persisted. Will I be able
to surface them in this roster obtained by Mylar? And how is the transport
between Mylar instances on the two machines to be connected once a
destination is selected so that I can participate in that as well?


"Scott Lewis" <slewis@composent.com> wrote in message
news:en3o4h$fpb$1@utils.eclipse.org...
> Hi Folks,
>
> Just to let everyone know, I've recently been making some significant
> improvements to the presence API:
>
> 1) Refactored things to have a chat manager
> (org.eclipse.presence.im.IChatManager) that manages the sending/receiving
> of chat messages. This moves a number of things out of
> IPresenceContainerAdapter directly, and puts them in the IChatManager.
> I've marked all deprecated methods, interfaces, and classes as
> @deprecated. I haven't removed them yet, as the old rosterview depends
> upon them (and we probably want to continue to use that UI for a short
> while as we create a new roster view, chat input/output, etc. See the
> IPresenceContainerAdapter.getChatManager() and
> org.eclipse.ecf.im.IChatManager interface (in CVS for latest).
>
> 2) Add several nice features to presence API for UI:
>
> a) Delivery of buddy pictures. See
> org.eclipse.ecf.presence.IPresence.getPictureData(). This will
> interoperate with the Google Talk (and other client's) delivery of little
> pictures for the roster list (the xmpp spec says png or jpg). All we need
> to do to have this happen is put a user interface together that shows the
> images when received.
>
> b) Sending/receiving of 'user is typing' messages. Strangely XMPP
> doesn't seem to have the notion of sending a 'user is now typing' message.
> But I added interfaces for sending and receiving such messages via
> IChatManager.getTypingSender() and ITypingMessageEvent (delivered to
> message listener). This is implemented in the ECF XMPP provider via the
> ECF shared object API...meaning that although it won't interoperate with
> other XMPP clients (since those clients don't send such messages), for two
> ECF clients they will send/receive 'user is typing' messages (even if
> using external servers like google's!).
>
> c) Sending/receiving of xhtml for messages (rather than just plain
> text). This allows *a lot* of UI formatting to occur for chat
> messages...and although I'm not an expert in JFace text display widgets I
> would imagine that it allows the rendering of html-formatted text very
> easily. This will interoperate with other XMPP clients (e.g. google talk,
> gaim, etc.) as this uses the XMPP xhtml extension. So, all the formatting
> done by these clients (e.g. font handling, links, etc) will be made
> available to any new ECF chat UI work. See the
> org.eclipse.ecf.presence.im.IXHTMLChatMessageEvent (delivered to an
> IIMMessageListener).
>
> 3) I refactored the xmpp provider plugin (org.eclipse.ecf.provider.xmpp)
> so the code is much more understandable (i.e. interfaces and classes in
> org.eclipse.ecf.provider.xmpp) and better organized. Also all the
> packages are now internal, so not considered API.
>
> Along with items on http://www.eclipse.org/ecf/plan.php (please take some
> of these on if you can)....there is more work planned: With the shared
> object API underneath, I can easily introduce any ECF client <-> ECF
> client protocol desired...e.g. for sending/receiving user info
> (email/other info) and/or Mylar context objects (so that, for example,
> buddies could be informed via presence state/roster list change messages
> when my active task changes).
>
> Thanks,
>
> Scott
>
>
>
Re: Presence API refactoring and improvement [message #609998 is a reply to message #609996] Fri, 12 January 2007 17:51 Go to previous messageGo to next message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
For Mylar the most interesting use case is to access local address
book to match between userid/email and the full name. List of users
would also help to implement type completion in the user-related fields
(assignee, cc list, etc).

Though I also second for the pluggability of the data sources. User
info can, for example, came from the Maven project model, which is
persisted externally. But ECF should provide a default/simple provider
that would have own persistence layer.

regards,
Eugene


Bill Joy wrote:
> Scott, I see from the provided link that you are planning on persisting
> buddy information and that other Eclipse plugins (such as Mylar) will want
> to use that roster to select a buddy then initiate some sort of object
> transfer.
>
> Is it going to be possible to contribute to that roster dynamically?
>
> For instance, I am using JmDNS (as encapsulated by ECF) to discover peers
> dynamically and so for me no roster needs to be persisted. Will I be able
> to surface them in this roster obtained by Mylar? And how is the transport
> between Mylar instances on the two machines to be connected once a
> destination is selected so that I can participate in that as well?
>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:en3o4h$fpb$1@utils.eclipse.org...
>
>> Hi Folks,
>>
>> Just to let everyone know, I've recently been making some significant
>> improvements to the presence API:
>>
>> 1) Refactored things to have a chat manager
>> (org.eclipse.presence.im.IChatManager) that manages the sending/receiving
>> of chat messages. This moves a number of things out of
>> IPresenceContainerAdapter directly, and puts them in the IChatManager.
>> I've marked all deprecated methods, interfaces, and classes as
>> @deprecated. I haven't removed them yet, as the old rosterview depends
>> upon them (and we probably want to continue to use that UI for a short
>> while as we create a new roster view, chat input/output, etc. See the
>> IPresenceContainerAdapter.getChatManager() and
>> org.eclipse.ecf.im.IChatManager interface (in CVS for latest).
>>
>> 2) Add several nice features to presence API for UI:
>>
>> a) Delivery of buddy pictures. See
>> org.eclipse.ecf.presence.IPresence.getPictureData(). This will
>> interoperate with the Google Talk (and other client's) delivery of little
>> pictures for the roster list (the xmpp spec says png or jpg). All we need
>> to do to have this happen is put a user interface together that shows the
>> images when received.
>>
>> b) Sending/receiving of 'user is typing' messages. Strangely XMPP
>> doesn't seem to have the notion of sending a 'user is now typing' message.
>> But I added interfaces for sending and receiving such messages via
>> IChatManager.getTypingSender() and ITypingMessageEvent (delivered to
>> message listener). This is implemented in the ECF XMPP provider via the
>> ECF shared object API...meaning that although it won't interoperate with
>> other XMPP clients (since those clients don't send such messages), for two
>> ECF clients they will send/receive 'user is typing' messages (even if
>> using external servers like google's!).
>>
>> c) Sending/receiving of xhtml for messages (rather than just plain
>> text). This allows *a lot* of UI formatting to occur for chat
>> messages...and although I'm not an expert in JFace text display widgets I
>> would imagine that it allows the rendering of html-formatted text very
>> easily. This will interoperate with other XMPP clients (e.g. google talk,
>> gaim, etc.) as this uses the XMPP xhtml extension. So, all the formatting
>> done by these clients (e.g. font handling, links, etc) will be made
>> available to any new ECF chat UI work. See the
>> org.eclipse.ecf.presence.im.IXHTMLChatMessageEvent (delivered to an
>> IIMMessageListener).
>>
>> 3) I refactored the xmpp provider plugin (org.eclipse.ecf.provider.xmpp)
>> so the code is much more understandable (i.e. interfaces and classes in
>> org.eclipse.ecf.provider.xmpp) and better organized. Also all the
>> packages are now internal, so not considered API.
>>
>> Along with items on http://www.eclipse.org/ecf/plan.php (please take some
>> of these on if you can)....there is more work planned: With the shared
>> object API underneath, I can easily introduce any ECF client <-> ECF
>> client protocol desired...e.g. for sending/receiving user info
>> (email/other info) and/or Mylar context objects (so that, for example,
>> buddies could be informed via presence state/roster list change messages
>> when my active task changes).
>>
>> Thanks,
>>
>> Scott
>>
>>
>>
>>
>
>
>
Re: Presence API refactoring and improvement [message #610000 is a reply to message #609996] Fri, 12 January 2007 18:14 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Bill,

Bill Joy wrote:
> Scott, I see from the provided link that you are planning on persisting
> buddy information and that other Eclipse plugins (such as Mylar) will want
> to use that roster to select a buddy then initiate some sort of object
> transfer.
>
> Is it going to be possible to contribute to that roster dynamically?

Yes. The newly created
org.eclipse.ecf.presence.ui.MultiRosterContentProvider can/could be
either extended or replaced. If replaced, some other content provider
can present whatever information is appropriate/relevant for UI.

Also, FYI...the new presence API has both presence and message
properties, which can be name->object pairs...and these will go through
XMPP (via xmpp server). This allows apps to associate whatever data
they wish with presence notifications without any mod to XMPP itself.

>
> For instance, I am using JmDNS (as encapsulated by ECF) to discover peers
> dynamically and so for me no roster needs to be persisted. Will I be able
> to surface them in this roster obtained by Mylar? And how is the transport
> between Mylar instances on the two machines to be connected once a
> destination is selected so that I can participate in that as well?

It would involve writing a content provider that 'knows about' Mylar
data structures, but that's enabled by extending (or replacing) the
MultiRosterContentProvider. This is likely the course that we will be
taking.

RE: persistence. The intention is to allow view (UI) implementers to
persist data that they wish to persist...possibly account info, buddy
list info, association with other account info (e.g. repository
accounts, etc). But this is quite easy to do via IMemento if that's
appropriate persistence mechanism for given app (depends upon whether
server, RCP, Eclipse-based client, etc).

Scott

>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:en3o4h$fpb$1@utils.eclipse.org...
>> Hi Folks,
>>
>> Just to let everyone know, I've recently been making some significant
>> improvements to the presence API:
>>
>> 1) Refactored things to have a chat manager
>> (org.eclipse.presence.im.IChatManager) that manages the sending/receiving
>> of chat messages. This moves a number of things out of
>> IPresenceContainerAdapter directly, and puts them in the IChatManager.
>> I've marked all deprecated methods, interfaces, and classes as
>> @deprecated. I haven't removed them yet, as the old rosterview depends
>> upon them (and we probably want to continue to use that UI for a short
>> while as we create a new roster view, chat input/output, etc. See the
>> IPresenceContainerAdapter.getChatManager() and
>> org.eclipse.ecf.im.IChatManager interface (in CVS for latest).
>>
>> 2) Add several nice features to presence API for UI:
>>
>> a) Delivery of buddy pictures. See
>> org.eclipse.ecf.presence.IPresence.getPictureData(). This will
>> interoperate with the Google Talk (and other client's) delivery of little
>> pictures for the roster list (the xmpp spec says png or jpg). All we need
>> to do to have this happen is put a user interface together that shows the
>> images when received.
>>
>> b) Sending/receiving of 'user is typing' messages. Strangely XMPP
>> doesn't seem to have the notion of sending a 'user is now typing' message.
>> But I added interfaces for sending and receiving such messages via
>> IChatManager.getTypingSender() and ITypingMessageEvent (delivered to
>> message listener). This is implemented in the ECF XMPP provider via the
>> ECF shared object API...meaning that although it won't interoperate with
>> other XMPP clients (since those clients don't send such messages), for two
>> ECF clients they will send/receive 'user is typing' messages (even if
>> using external servers like google's!).
>>
>> c) Sending/receiving of xhtml for messages (rather than just plain
>> text). This allows *a lot* of UI formatting to occur for chat
>> messages...and although I'm not an expert in JFace text display widgets I
>> would imagine that it allows the rendering of html-formatted text very
>> easily. This will interoperate with other XMPP clients (e.g. google talk,
>> gaim, etc.) as this uses the XMPP xhtml extension. So, all the formatting
>> done by these clients (e.g. font handling, links, etc) will be made
>> available to any new ECF chat UI work. See the
>> org.eclipse.ecf.presence.im.IXHTMLChatMessageEvent (delivered to an
>> IIMMessageListener).
>>
>> 3) I refactored the xmpp provider plugin (org.eclipse.ecf.provider.xmpp)
>> so the code is much more understandable (i.e. interfaces and classes in
>> org.eclipse.ecf.provider.xmpp) and better organized. Also all the
>> packages are now internal, so not considered API.
>>
>> Along with items on http://www.eclipse.org/ecf/plan.php (please take some
>> of these on if you can)....there is more work planned: With the shared
>> object API underneath, I can easily introduce any ECF client <-> ECF
>> client protocol desired...e.g. for sending/receiving user info
>> (email/other info) and/or Mylar context objects (so that, for example,
>> buddies could be informed via presence state/roster list change messages
>> when my active task changes).
>>
>> Thanks,
>>
>> Scott
>>
>>
>>
>
>
Re: Presence API refactoring and improvement [message #610001 is a reply to message #609998] Fri, 12 January 2007 19:19 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Eugene,

Eugene Kuleshov wrote:
>
> For Mylar the most interesting use case is to access local address book
> to match between userid/email and the full name. List of users would
> also help to implement type completion in the user-related fields
> (assignee, cc list, etc).
>
> Though I also second for the pluggability of the data sources. User
> info can, for example, came from the Maven project model, which is
> persisted externally. But ECF should provide a default/simple provider
> that would have own persistence layer.

ECF can/will provide a default/simple roster view that locally persists
some of the info in a roster (e.g. account info and probably basic
user/presence info). This is easy to do with the existing or new
content provider (MultiRosterContentProvider). But the offline/local
info will necessarily be quite limited in it's usefulness to the user
while offline.

Google Talk's behavior is an instructive example...although the 'last
known contents' of the roster list is persisted by GT locally, it's not
really that useful while offline, as you (obviously) can't send people
messages, can't receive anything from them, can't add/remove people from
roster, can't get/send any new presence info, can't initiate chat or
phone call, etc. What it can be used for is to store things like
presence info, email address, other things previosuly sent as presence
and message properties...and then request/get updates/synchronize on
those things when back online/reconnected (i.e. request/get presence
updates).

Another example is Mylar itself, of course...if offline for several days
(which I was over holidays) the task list for the eclipse.org repository
bugs/tasks obviously didn't change locally...even though they changed in
repository because of others making bug fixes, adding enhancements, etc.

ECF's basic/example roster view can/will provide code for
storing/restoring the basic roster info provided by presence API
implementers (XMPP etc), and of course allow extension or custom
providers and view extensions to store their own 'stuff' in addition.
But obviously in the case of custom providers the sharing of new/other
stuff via presence and/or message properties will have to deal with the
storing/restoring of those data (because ECF doesn't know anything about
it). And there are, of course, a number of mechanisms for storing such
data provided by Platform...depending upon whether that's RCP, Eclipse
IDE, and/or server app, and the use cases WRT security of storage and
integration with other applications...like Mylar.

Scott
Re: Presence API refactoring and improvement [message #610003 is a reply to message #610001] Fri, 12 January 2007 21:15 Go to previous messageGo to next message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
Scott,

At this moment I have no interest in ECF's communication features and
my comment was related exclusively to the identity management.

What would be really interesting if ECF would have some UI (btw, you
should stop calling those "examples") that would allow to manager
identities across different sources. So, you can see that same user has
identities in gtalk, eclipse bugzilla, codehaus jira, etc...

regards,
Eugene


Scott Lewis wrote:
>> For Mylar the most interesting use case is to access local address
>> book to match between userid/email and the full name. List of users
>> would also help to implement type completion in the user-related
>> fields (assignee, cc list, etc).
>>
>> Though I also second for the pluggability of the data sources. User
>> info can, for example, came from the Maven project model, which is
>> persisted externally. But ECF should provide a default/simple
>> provider that would have own persistence layer.
>
> ECF can/will provide a default/simple roster view that locally
> persists some of the info in a roster (e.g. account info and probably
> basic user/presence info). This is easy to do with the existing or
> new content provider (MultiRosterContentProvider). But the
> offline/local info will necessarily be quite limited in it's
> usefulness to the user while offline.
>
> Google Talk's behavior is an instructive example...although the 'last
> known contents' of the roster list is persisted by GT locally, it's
> not really that useful while offline, as you (obviously) can't send
> people messages, can't receive anything from them, can't add/remove
> people from roster, can't get/send any new presence info, can't
> initiate chat or phone call, etc. What it can be used for is to store
> things like presence info, email address, other things previosuly sent
> as presence and message properties...and then request/get
> updates/synchronize on those things when back online/reconnected (i.e.
> request/get presence updates).
>
> Another example is Mylar itself, of course...if offline for several
> days (which I was over holidays) the task list for the eclipse.org
> repository bugs/tasks obviously didn't change locally...even though
> they changed in repository because of others making bug fixes, adding
> enhancements, etc.
>
> ECF's basic/example roster view can/will provide code for
> storing/restoring the basic roster info provided by presence API
> implementers (XMPP etc), and of course allow extension or custom
> providers and view extensions to store their own 'stuff' in addition.
> But obviously in the case of custom providers the sharing of new/other
> stuff via presence and/or message properties will have to deal with
> the storing/restoring of those data (because ECF doesn't know anything
> about it). And there are, of course, a number of mechanisms for
> storing such data provided by Platform...depending upon whether that's
> RCP, Eclipse IDE, and/or server app, and the use cases WRT security of
> storage and integration with other applications...like Mylar.
>
> Scott
Re: Presence API refactoring and improvement [message #612039 is a reply to message #610000] Fri, 12 January 2007 21:24 Go to previous messageGo to next message
Bill Joy is currently offline Bill JoyFriend
Messages: 60
Registered: July 2009
Member
It looks like a MultiRosterContentProvider implementation is intended to
supply content for a tree that lives in a MultiRosterView.

Does this mean that the Mylar interface would involve dragging a
serializable task onto a tree element to send it to a particular buddy? (I
was under the assumption that the proposed public roster would be more like
a list of buddy objects with a global accessor.)

I am trying to figure out what changes are needed to my current code -- it
uses a tree to show available peers (which is not in a MultiRosterView) and
does not use any ECF extension points currently so it does not surface any
presence information.

Do I have to refactor my code into an ECF container, implement the presence
API within it, and rely on MultiRosterView to display my peers in order to
have plugins like Mylar be able to see my peers and send/receive what Mylar
wants transported to them?


"Scott Lewis" <slewis@composent.com> wrote in message
news:45A7D01C.7000300@composent.com...
> Hi Bill,
>
> Bill Joy wrote:
>> Scott, I see from the provided link that you are planning on persisting
>> buddy information and that other Eclipse plugins (such as Mylar) will
>> want to use that roster to select a buddy then initiate some sort of
>> object transfer.
>>
>> Is it going to be possible to contribute to that roster dynamically?
>
> Yes. The newly created
> org.eclipse.ecf.presence.ui.MultiRosterContentProvider can/could be either
> extended or replaced. If replaced, some other content provider can
> present whatever information is appropriate/relevant for UI.
>
> Also, FYI...the new presence API has both presence and message properties,
> which can be name->object pairs...and these will go through XMPP (via xmpp
> server). This allows apps to associate whatever data they wish with
> presence notifications without any mod to XMPP itself.
>
>>
>> For instance, I am using JmDNS (as encapsulated by ECF) to discover peers
>> dynamically and so for me no roster needs to be persisted. Will I be
>> able to surface them in this roster obtained by Mylar? And how is the
>> transport between Mylar instances on the two machines to be connected
>> once a destination is selected so that I can participate in that as well?
>
> It would involve writing a content provider that 'knows about' Mylar data
> structures, but that's enabled by extending (or replacing) the
> MultiRosterContentProvider. This is likely the course that we will be
> taking.
>
> RE: persistence. The intention is to allow view (UI) implementers to
> persist data that they wish to persist...possibly account info, buddy list
> info, association with other account info (e.g. repository accounts, etc).
> But this is quite easy to do via IMemento if that's appropriate
> persistence mechanism for given app (depends upon whether server, RCP,
> Eclipse-based client, etc).
>
> Scott
>
>>
>>
>> "Scott Lewis" <slewis@composent.com> wrote in message
>> news:en3o4h$fpb$1@utils.eclipse.org...
>>> Hi Folks,
>>>
>>> Just to let everyone know, I've recently been making some significant
>>> improvements to the presence API:
>>>
>>> 1) Refactored things to have a chat manager
>>> (org.eclipse.presence.im.IChatManager) that manages the
>>> sending/receiving of chat messages. This moves a number of things out
>>> of IPresenceContainerAdapter directly, and puts them in the
>>> IChatManager. I've marked all deprecated methods, interfaces, and
>>> classes as @deprecated. I haven't removed them yet, as the old
>>> rosterview depends upon them (and we probably want to continue to use
>>> that UI for a short while as we create a new roster view, chat
>>> input/output, etc. See the IPresenceContainerAdapter.getChatManager()
>>> and org.eclipse.ecf.im.IChatManager interface (in CVS for latest).
>>>
>>> 2) Add several nice features to presence API for UI:
>>>
>>> a) Delivery of buddy pictures. See
>>> org.eclipse.ecf.presence.IPresence.getPictureData(). This will
>>> interoperate with the Google Talk (and other client's) delivery of
>>> little pictures for the roster list (the xmpp spec says png or jpg). All
>>> we need to do to have this happen is put a user interface together that
>>> shows the images when received.
>>>
>>> b) Sending/receiving of 'user is typing' messages. Strangely XMPP
>>> doesn't seem to have the notion of sending a 'user is now typing'
>>> message. But I added interfaces for sending and receiving such messages
>>> via IChatManager.getTypingSender() and ITypingMessageEvent (delivered to
>>> message listener). This is implemented in the ECF XMPP provider via the
>>> ECF shared object API...meaning that although it won't interoperate with
>>> other XMPP clients (since those clients don't send such messages), for
>>> two ECF clients they will send/receive 'user is typing' messages (even
>>> if using external servers like google's!).
>>>
>>> c) Sending/receiving of xhtml for messages (rather than just plain
>>> text). This allows *a lot* of UI formatting to occur for chat
>>> messages...and although I'm not an expert in JFace text display widgets
>>> I would imagine that it allows the rendering of html-formatted text very
>>> easily. This will interoperate with other XMPP clients (e.g. google
>>> talk, gaim, etc.) as this uses the XMPP xhtml extension. So, all the
>>> formatting done by these clients (e.g. font handling, links, etc) will
>>> be made available to any new ECF chat UI work. See the
>>> org.eclipse.ecf.presence.im.IXHTMLChatMessageEvent (delivered to an
>>> IIMMessageListener).
>>>
>>> 3) I refactored the xmpp provider plugin (org.eclipse.ecf.provider.xmpp)
>>> so the code is much more understandable (i.e. interfaces and classes in
>>> org.eclipse.ecf.provider.xmpp) and better organized. Also all the
>>> packages are now internal, so not considered API.
>>>
>>> Along with items on http://www.eclipse.org/ecf/plan.php (please take
>>> some of these on if you can)....there is more work planned: With the
>>> shared object API underneath, I can easily introduce any ECF client <->
>>> ECF client protocol desired...e.g. for sending/receiving user info
>>> (email/other info) and/or Mylar context objects (so that, for example,
>>> buddies could be informed via presence state/roster list change messages
>>> when my active task changes).
>>>
>>> Thanks,
>>>
>>> Scott
>>>
>>>
>>>
>>
Re: Presence API refactoring and improvement [message #612040 is a reply to message #610003] Fri, 12 January 2007 23:11 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Eugene,

Eugene Kuleshov wrote:
> Scott,
>
> At this moment I have no interest in ECF's communication features and
> my comment was related exclusively to the identity management.


I'm not sure why you would expect that ECF would deliver all the
identity management features you are looking for...as that has never
been in ECF's charter/plans (rather the communication features have
always been paramount...hence eCf).

I would also like to see lots more in Eclipse WRT identity management as
well as authentication and authorization, but I don't think ECF can
really address all those issues on its own...as much as I would like to.

>
> What would be really interesting if ECF would have some UI (btw, you
> should stop calling those "examples")


No, they are indeed examples/exemplary applications. The communications
functions provided by ECF are intended to be used on servers, 'small UI'
apps (e.g. eRCP), and large RCP apps (Eclipse). Therefore, specific UIs
for one of these environments are examples/exemplary applications
relative to the framework.

that would allow to manager
> identities across different sources.

I think it would be appropriate to qualify your statement: "What would
be really interesting *to me* is if ECF would have some UI..."

>So, you can see that same user has
> identities in gtalk, eclipse bugzilla, codehaus jira, etc...

Sounds more like a requirement for Equinox+JAAS, and/or Higgins...since
those are the Eclipse projects whose charter includes
platform/framework-level identity management. Or, you could propose a
project that meets your own desires here and get it
established/contribute to it, but it's not reasonable to think that your
own individual desires are ECF's responsibility...at least when they are
clearly outside ECF's scope.

I understand that you would like more in terms of identity management,
and strongly share that desire with you...I've personally tried/been
supportive/participative of the projects that have identity management
in scope...and ECF does do some interesting things with
defining/allowing extensible IDs appropriate for use within an identity
management system (which we have offered to contribute to other projects).

But in my view it would not be appropriate for ECF to focus exclusively
on identity management...particularly since we do not have the means to
do such work alongside the other things that *are* clearly in scope.

Scott
Re: Presence API refactoring and improvement [message #612041 is a reply to message #612039] Fri, 12 January 2007 23:43 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Bill,

Bill Joy wrote:
> It looks like a MultiRosterContentProvider implementation is intended to
> supply content for a tree that lives in a MultiRosterView.
>
> Does this mean that the Mylar interface would involve dragging a
> serializable task onto a tree element to send it to a particular buddy?


Although this is a possible use case, IMHO it's not a particularly good
one. That is, I think that exchanging Mylar tasks between users,
although technically possible doable, is not the best use case. There
are social conventions/appropriateness considerations here that matter a
lot...for example, how am I supposed to interpret you giving me a number
of tasks? There is lots of room for misinterpretation about such
activities.

I think that there are lots of other use cases for sharing Mylar
information that are probably more useful in teams working with tasks:
e.g. automatically updating other team members about currently active
task, sharing task context information via presence, IM notification
about task state changes (maybe with visual differences in user's
presence). But for these as well I think it's important to be sensitive
to social appropriateness concerns.

(I
> was under the assumption that the proposed public roster would be more like
> a list of buddy objects with a global accessor.)

The access to the IRoster instance (via IRosterManager.getRoster()) is
essentially this (a list of IRosterEntry objects...which has presence
info [IPresence] about a given user).

The existing MultiRosterContentProvider uses these interfaces (via an
IWorkbenchAdapter...see RosterWorkbenchAdapterFactory) to get the data
from the roster for presentation in the hierarchical tree viewer.
Extensions or replacements for MultiRosterContentProvider could access
the roster in desired manner along with other info of own provider (e.g.
peers)...and even mix them together that is what is desired.


>
> I am trying to figure out what changes are needed to my current code -- it
> uses a tree to show available peers (which is not in a MultiRosterView) and
> does not use any ECF extension points currently so it does not surface any
> presence information.


I'm not sure I understand...you now show available peers in a tree view,
and want to include in that tree view data from the xmpp-provided
roster? Or do you just want to present the information that you are
gathering from peers?

>
> Do I have to refactor my code into an ECF container, implement the presence
> API within it, and rely on MultiRosterView to display my peers in order to
> have plugins like Mylar be able to see my peers and send/receive what Mylar
> wants transported to them?


No, I wouldn't expect so.

Are you looking to visually integrate the information that you are
collecting about peers with XMPP roster info (i.e. mix peers with roster
entries)? If so, then extending or replacing the
MultiRosterContentProvider would be appropriate.

If you just want to present and update a list of peers gathered via some
other means (e.g. discovery API) then I don't think the presence API is
really appropriate at all.


Scott


>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:45A7D01C.7000300@composent.com...
>> Hi Bill,
>>
>> Bill Joy wrote:
>>> Scott, I see from the provided link that you are planning on persisting
>>> buddy information and that other Eclipse plugins (such as Mylar) will
>>> want to use that roster to select a buddy then initiate some sort of
>>> object transfer.
>>>
>>> Is it going to be possible to contribute to that roster dynamically?
>> Yes. The newly created
>> org.eclipse.ecf.presence.ui.MultiRosterContentProvider can/could be either
>> extended or replaced. If replaced, some other content provider can
>> present whatever information is appropriate/relevant for UI.
>>
>> Also, FYI...the new presence API has both presence and message properties,
>> which can be name->object pairs...and these will go through XMPP (via xmpp
>> server). This allows apps to associate whatever data they wish with
>> presence notifications without any mod to XMPP itself.
>>
>>> For instance, I am using JmDNS (as encapsulated by ECF) to discover peers
>>> dynamically and so for me no roster needs to be persisted. Will I be
>>> able to surface them in this roster obtained by Mylar? And how is the
>>> transport between Mylar instances on the two machines to be connected
>>> once a destination is selected so that I can participate in that as well?
>> It would involve writing a content provider that 'knows about' Mylar data
>> structures, but that's enabled by extending (or replacing) the
>> MultiRosterContentProvider. This is likely the course that we will be
>> taking.
>>
>> RE: persistence. The intention is to allow view (UI) implementers to
>> persist data that they wish to persist...possibly account info, buddy list
>> info, association with other account info (e.g. repository accounts, etc).
>> But this is quite easy to do via IMemento if that's appropriate
>> persistence mechanism for given app (depends upon whether server, RCP,
>> Eclipse-based client, etc).
>>
>> Scott
>>
>>>
>>> "Scott Lewis" <slewis@composent.com> wrote in message
>>> news:en3o4h$fpb$1@utils.eclipse.org...
>>>> Hi Folks,
>>>>
>>>> Just to let everyone know, I've recently been making some significant
>>>> improvements to the presence API:
>>>>
>>>> 1) Refactored things to have a chat manager
>>>> (org.eclipse.presence.im.IChatManager) that manages the
>>>> sending/receiving of chat messages. This moves a number of things out
>>>> of IPresenceContainerAdapter directly, and puts them in the
>>>> IChatManager. I've marked all deprecated methods, interfaces, and
>>>> classes as @deprecated. I haven't removed them yet, as the old
>>>> rosterview depends upon them (and we probably want to continue to use
>>>> that UI for a short while as we create a new roster view, chat
>>>> input/output, etc. See the IPresenceContainerAdapter.getChatManager()
>>>> and org.eclipse.ecf.im.IChatManager interface (in CVS for latest).
>>>>
>>>> 2) Add several nice features to presence API for UI:
>>>>
>>>> a) Delivery of buddy pictures. See
>>>> org.eclipse.ecf.presence.IPresence.getPictureData(). This will
>>>> interoperate with the Google Talk (and other client's) delivery of
>>>> little pictures for the roster list (the xmpp spec says png or jpg). All
>>>> we need to do to have this happen is put a user interface together that
>>>> shows the images when received.
>>>>
>>>> b) Sending/receiving of 'user is typing' messages. Strangely XMPP
>>>> doesn't seem to have the notion of sending a 'user is now typing'
>>>> message. But I added interfaces for sending and receiving such messages
>>>> via IChatManager.getTypingSender() and ITypingMessageEvent (delivered to
>>>> message listener). This is implemented in the ECF XMPP provider via the
>>>> ECF shared object API...meaning that although it won't interoperate with
>>>> other XMPP clients (since those clients don't send such messages), for
>>>> two ECF clients they will send/receive 'user is typing' messages (even
>>>> if using external servers like google's!).
>>>>
>>>> c) Sending/receiving of xhtml for messages (rather than just plain
>>>> text). This allows *a lot* of UI formatting to occur for chat
>>>> messages...and although I'm not an expert in JFace text display widgets
>>>> I would imagine that it allows the rendering of html-formatted text very
>>>> easily. This will interoperate with other XMPP clients (e.g. google
>>>> talk, gaim, etc.) as this uses the XMPP xhtml extension. So, all the
>>>> formatting done by these clients (e.g. font handling, links, etc) will
>>>> be made available to any new ECF chat UI work. See the
>>>> org.eclipse.ecf.presence.im.IXHTMLChatMessageEvent (delivered to an
>>>> IIMMessageListener).
>>>>
>>>> 3) I refactored the xmpp provider plugin (org.eclipse.ecf.provider.xmpp)
>>>> so the code is much more understandable (i.e. interfaces and classes in
>>>> org.eclipse.ecf.provider.xmpp) and better organized. Also all the
>>>> packages are now internal, so not considered API.
>>>>
>>>> Along with items on http://www.eclipse.org/ecf/plan.php (please take
>>>> some of these on if you can)....there is more work planned: With the
>>>> shared object API underneath, I can easily introduce any ECF client <->
>>>> ECF client protocol desired...e.g. for sending/receiving user info
>>>> (email/other info) and/or Mylar context objects (so that, for example,
>>>> buddies could be informed via presence state/roster list change messages
>>>> when my active task changes).
>>>>
>>>> Thanks,
>>>>
>>>> Scott
>>>>
>>>>
>>>>
>
Re: Presence API refactoring and improvement [message #612042 is a reply to message #612041] Sat, 13 January 2007 00:17 Go to previous message
Bill Joy is currently offline Bill JoyFriend
Messages: 60
Registered: July 2009
Member
Thanks Scott, I think I am now oriented enough to start looking in the right
places for the details.


"Scott Lewis" <slewis@composent.com> wrote in message
news:45A81D32.5020105@composent.com...
> Hi Bill,
>
> Bill Joy wrote:
>> It looks like a MultiRosterContentProvider implementation is intended to
>> supply content for a tree that lives in a MultiRosterView.
>>
>> Does this mean that the Mylar interface would involve dragging a
>> serializable task onto a tree element to send it to a particular buddy?
>
>
> Although this is a possible use case, IMHO it's not a particularly good
> one. That is, I think that exchanging Mylar tasks between users, although
> technically possible doable, is not the best use case. There are social
> conventions/appropriateness considerations here that matter a lot...for
> example, how am I supposed to interpret you giving me a number of tasks?
> There is lots of room for misinterpretation about such activities.
>
> I think that there are lots of other use cases for sharing Mylar
> information that are probably more useful in teams working with tasks:
> e.g. automatically updating other team members about currently active
> task, sharing task context information via presence, IM notification about
> task state changes (maybe with visual differences in user's presence).
> But for these as well I think it's important to be sensitive to social
> appropriateness concerns.
>
> (I
>> was under the assumption that the proposed public roster would be more
>> like a list of buddy objects with a global accessor.)
>
> The access to the IRoster instance (via IRosterManager.getRoster()) is
> essentially this (a list of IRosterEntry objects...which has presence info
> [IPresence] about a given user).
>
> The existing MultiRosterContentProvider uses these interfaces (via an
> IWorkbenchAdapter...see RosterWorkbenchAdapterFactory) to get the data
> from the roster for presentation in the hierarchical tree viewer.
> Extensions or replacements for MultiRosterContentProvider could access the
> roster in desired manner along with other info of own provider (e.g.
> peers)...and even mix them together that is what is desired.
>
>
>>
>> I am trying to figure out what changes are needed to my current code --
>> it uses a tree to show available peers (which is not in a
>> MultiRosterView) and does not use any ECF extension points currently so
>> it does not surface any presence information.
>
>
> I'm not sure I understand...you now show available peers in a tree view,
> and want to include in that tree view data from the xmpp-provided roster?
> Or do you just want to present the information that you are gathering from
> peers?
>
>>
>> Do I have to refactor my code into an ECF container, implement the
>> presence API within it, and rely on MultiRosterView to display my peers
>> in order to have plugins like Mylar be able to see my peers and
>> send/receive what Mylar wants transported to them?
>
>
> No, I wouldn't expect so.
>
> Are you looking to visually integrate the information that you are
> collecting about peers with XMPP roster info (i.e. mix peers with roster
> entries)? If so, then extending or replacing the
> MultiRosterContentProvider would be appropriate.
>
> If you just want to present and update a list of peers gathered via some
> other means (e.g. discovery API) then I don't think the presence API is
> really appropriate at all.
>
>
> Scott
>
>
>>
>>
>> "Scott Lewis" <slewis@composent.com> wrote in message
>> news:45A7D01C.7000300@composent.com...
>>> Hi Bill,
>>>
>>> Bill Joy wrote:
>>>> Scott, I see from the provided link that you are planning on persisting
>>>> buddy information and that other Eclipse plugins (such as Mylar) will
>>>> want to use that roster to select a buddy then initiate some sort of
>>>> object transfer.
>>>>
>>>> Is it going to be possible to contribute to that roster dynamically?
>>> Yes. The newly created
>>> org.eclipse.ecf.presence.ui.MultiRosterContentProvider can/could be
>>> either extended or replaced. If replaced, some other content provider
>>> can present whatever information is appropriate/relevant for UI.
>>>
>>> Also, FYI...the new presence API has both presence and message
>>> properties, which can be name->object pairs...and these will go through
>>> XMPP (via xmpp server). This allows apps to associate whatever data
>>> they wish with presence notifications without any mod to XMPP itself.
>>>
>>>> For instance, I am using JmDNS (as encapsulated by ECF) to discover
>>>> peers dynamically and so for me no roster needs to be persisted. Will
>>>> I be able to surface them in this roster obtained by Mylar? And how is
>>>> the transport between Mylar instances on the two machines to be
>>>> connected once a destination is selected so that I can participate in
>>>> that as well?
>>> It would involve writing a content provider that 'knows about' Mylar
>>> data structures, but that's enabled by extending (or replacing) the
>>> MultiRosterContentProvider. This is likely the course that we will be
>>> taking.
>>>
>>> RE: persistence. The intention is to allow view (UI) implementers to
>>> persist data that they wish to persist...possibly account info, buddy
>>> list info, association with other account info (e.g. repository
>>> accounts, etc). But this is quite easy to do via IMemento if that's
>>> appropriate persistence mechanism for given app (depends upon whether
>>> server, RCP, Eclipse-based client, etc).
>>>
>>> Scott
>>>
>>>>
>>>> "Scott Lewis" <slewis@composent.com> wrote in message
>>>> news:en3o4h$fpb$1@utils.eclipse.org...
>>>>> Hi Folks,
>>>>>
>>>>> Just to let everyone know, I've recently been making some significant
>>>>> improvements to the presence API:
>>>>>
>>>>> 1) Refactored things to have a chat manager
>>>>> (org.eclipse.presence.im.IChatManager) that manages the
>>>>> sending/receiving of chat messages. This moves a number of things out
>>>>> of IPresenceContainerAdapter directly, and puts them in the
>>>>> IChatManager. I've marked all deprecated methods, interfaces, and
>>>>> classes as @deprecated. I haven't removed them yet, as the old
>>>>> rosterview depends upon them (and we probably want to continue to use
>>>>> that UI for a short while as we create a new roster view, chat
>>>>> input/output, etc. See the IPresenceContainerAdapter.getChatManager()
>>>>> and org.eclipse.ecf.im.IChatManager interface (in CVS for latest).
>>>>>
>>>>> 2) Add several nice features to presence API for UI:
>>>>>
>>>>> a) Delivery of buddy pictures. See
>>>>> org.eclipse.ecf.presence.IPresence.getPictureData(). This will
>>>>> interoperate with the Google Talk (and other client's) delivery of
>>>>> little pictures for the roster list (the xmpp spec says png or jpg).
>>>>> All we need to do to have this happen is put a user interface together
>>>>> that shows the images when received.
>>>>>
>>>>> b) Sending/receiving of 'user is typing' messages. Strangely XMPP
>>>>> doesn't seem to have the notion of sending a 'user is now typing'
>>>>> message. But I added interfaces for sending and receiving such
>>>>> messages via IChatManager.getTypingSender() and ITypingMessageEvent
>>>>> (delivered to message listener). This is implemented in the ECF XMPP
>>>>> provider via the ECF shared object API...meaning that although it
>>>>> won't interoperate with other XMPP clients (since those clients don't
>>>>> send such messages), for two ECF clients they will send/receive 'user
>>>>> is typing' messages (even if using external servers like google's!).
>>>>>
>>>>> c) Sending/receiving of xhtml for messages (rather than just plain
>>>>> text). This allows *a lot* of UI formatting to occur for chat
>>>>> messages...and although I'm not an expert in JFace text display
>>>>> widgets I would imagine that it allows the rendering of html-formatted
>>>>> text very easily. This will interoperate with other XMPP clients
>>>>> (e.g. google talk, gaim, etc.) as this uses the XMPP xhtml extension.
>>>>> So, all the formatting done by these clients (e.g. font handling,
>>>>> links, etc) will be made available to any new ECF chat UI work. See
>>>>> the org.eclipse.ecf.presence.im.IXHTMLChatMessageEvent (delivered to
>>>>> an IIMMessageListener).
>>>>>
>>>>> 3) I refactored the xmpp provider plugin
>>>>> (org.eclipse.ecf.provider.xmpp) so the code is much more
>>>>> understandable (i.e. interfaces and classes in
>>>>> org.eclipse.ecf.provider.xmpp) and better organized. Also all the
>>>>> packages are now internal, so not considered API.
>>>>>
>>>>> Along with items on http://www.eclipse.org/ecf/plan.php (please take
>>>>> some of these on if you can)....there is more work planned: With the
>>>>> shared object API underneath, I can easily introduce any ECF client
>>>>> <-> ECF client protocol desired...e.g. for sending/receiving user info
>>>>> (email/other info) and/or Mylar context objects (so that, for example,
>>>>> buddies could be informed via presence state/roster list change
>>>>> messages when my active task changes).
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>>
>>
Previous Topic:ECF 0.9.5 stable
Next Topic:ECF 0.9.6 stable
Goto Forum:
  


Current Time: Fri Mar 29 15:24:22 GMT 2024

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

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

Back to the top