[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Presence API + UI considerations

Hi Remy,

Remy Chi Jian Suen wrote:
Hi everyone,

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

Currently, there's no notification upon sending.

Am I supposed to just tack code after the sendMessage(String)
call in IChatMessageSender?

Yes, that's the expectation.

Or is the API just missing something here?

It's a judgment call as to whether this means it's missing anything. Although it's a notification that could easily be added, given the ability to have the code 'know' when messages are sent (because it calls 'sendMessage'), it's not obvious (to me) whether the API really needs such a notification. And we've tried to keep the API as simple as possible. That's the trade off. Maybe it does...any other comments?

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.

Yes, you are definitely right about this. I'll add some to the docs for the message listener.

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.

I think the answer is could be yes. Although it would be nice to avoid additional dependencies, for UI plugins this isn't a very substantial concern, as just by being dependent upon jface, help, org.eclipse.ui and others the available runtimes are relatively limited (and these dependencies don't even come from ECF).

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?

[FYI this is thinking out loud here]

This problem isn't specific to ECF code...it seems more generic to Eclipse as it gets at the appropriate way to cleanly separate UI (which is almost always environment dependent) vs. behavior (which tries/wants not to be).

I think that perhaps one way to deal with this is that some ECF 'action' interfaces should be created (that descend from IAction* interfaces). This would allow us and others to separate UI code from the code that must depend upon ECF adapter APIs (like filetransfer). So, for example, what if we created an interface like this:

(in org.eclipse.ecf.ui)

public interface IContainerAction extends IAction {
    public void setContainer(IContainer container);

And then in org.eclipse.ecf.presence.ui had some concrete implementations of (e.g.) IContainer action FileTransferSendAction :

public FileTransferSendAction extends SomeActionSuperclass implements IContainerAction {

    IOutgoingFileTransferContainerAdapter fileTransfer = null;

pubic void setContainer(IContainer container) {
fileTransfer = (IOutgoingFileTransferContainerAdapter) container.getAdapter(IOutgoingFileTransferContainerAdapter.class);

    public void run() {
    if (fileTransfer == null) throw;
    else...do what you need to do to send file.

Also, we could have sub interfaces of IActionDelegate interfaces that pass in IContainer instances during delegate initialization.

I have a little bit of concern about any such approach, however, because I'm at least peripherally aware of changes that are happening in the whole action framework (in the Eclipse platform), and I haven't studied them/know what is happening there well enough yet.

Boris, Chris A, Peter...others could you comment on any of this?

My $0.02.


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

ecf-dev mailing list