[ecf-dev] Presence API + UI considerations

["Remy Chi Jian Suen" <remy.suen@xxxxxxxxx>]

Hi everyone,

API:
How is the presence API's message listeners supposed to work? Are they
supposed to only fire when the local user receives a message?

If yes, how do I figure out who the message is being sent to? I could
call getThreadID()...but that may return null.

If not, how I am supposed to know when the local user has _sent_ a
message? Am I supposed to just tack code after the sendMessage(String)
call in IChatMessageSender?

Or is the API just missing something here? If not, I think it should
at least have clear javadocs that states "This listener will only fire
for messages the local user receives" or something of that sort.

UI:
I did some work on the MultiRosterView class in
org.eclipse.ecf.presence.ui this past weekend but have temporarily put
it on hold due to the issue of "file transfer". In the past, I've
advocated heavily for the removal of dependencies and miscellaneous
J2SE classes and API changes so that ECF could run smaller runtime
environments (CDC/Foundation, eRCP, etc.). Now once again, I have some
dependency/API considerations to bring up.

Any respectable IM client/protocol nowadays supports file transfers.
One that wouldn't support such a feature would probably be like an
email client that didn't support file attachments (that's a little bit
extreme, but you get the idea). So of course, the question here is
should org.eclipse.ecf.presence.ui have a dependency on
org.eclipse.ecf.filetransfer and org.eclipse.ecf.filetransfer.ui? If
yes, then this discussion is over.

If not, how can we add file transferring capabilities to the
MultiRosterView? Do we create a bridge plug-in that has a dependency
on both APIs (I can't even begin to imagine what its bundle ID would
be)? Actually, that scenario wouldn't even really fix the problem. In
the case of contributing to the context menu of the MultiRosterView,
all our action delegate gets is an IRosterEntry at the end of the day.
I mean sure, we can recursively go up the food chain and retrieve an
IRoster instance, but how do we get the parent
IPresenceContainerAdapter or IContainer instance so that we can call
getAdapter(IOutgoingFileTransferContainerAdapter.class) on _that_?
IRoster implements IAdaptable, but I'm don't think it's reasonable to
expect everyone that implements that interface to put in an
appropriate return statement given the file transferring class above.

One also needs to consider the UI provider plug-in
(org.eclipse.ecf.provider.xmpp.ui is an example of what I am referring
to). Our XMPP provider currently implements file sending, but when it
supports the receiving of files, what do we do? Does that plug-in now
add a dependency to org.eclipse.ecf.filetransfer.ui? Heck, is it even
realistic to imagine that anyone would not want to support file
transfer capabilities? If someone out there does indeed not want file
transfer capabilities, what other oddly named bundle would they have
to plug into the platform? How would that plug-in get the IContainer
instance that was created after the wizard did its thing?

I think I may be missing some other details, but I'm done for now.

Regards,
Rem