Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] A model proposal

Hi Ken,

Ken Gilmer wrote:

Hey Scott -

I like your idea. To make sure I understand, this approach would allow someone to create presence logic without an UI.

That's right. The org.eclipse.ecf.presence plugin (with all the presence logic/model) does not have any UI dependencies at all (and is perfectly suitable for use in servers, headless clients, etc.). This is also true, incidently for the org.eclipse.ecf.discovery (discovery API), org.eclipse.ecf.datashare (datashare API), org.eclipse.ecf.sharedobject, org.eclipse.ecf.filetransfer, and org.eclipse.ecf.remoteservices. All 'pure' messaging/communications APIs with dependencies only on CDC 1.0/Foundation 1.0, jre 1.4+, core runtime, and jobs api.

The main difference with this restructuring is that the shared 'model' (for presence API it's the user's buddy list or roster) is also defined and managed by the provider (e.g. xmpp, yahoo, etc). The new model is in org.eclipse.ecf.presence.roster package. This model is suitable for use underlying a very simple content provider (implements ITreeContentProvider). The content provider *does* have dependencies on jface/UI classes but this is in the new plugin org.eclipse.ecf.presence.ui. (see class MultiRosterContentProvider...this is a content provider that is based upon the org.eclipse.ecf.presence.roster model, AND the jface interfaces/classes). It's called 'MultiRosterContentProvider' because it supports the display of multiple rosters (i.e. for different accounts).

To understand how much this saves the UI programmer see the code in org.eclipse.ecf.presence.ui.MultiRosterView. This is a view based upon the MultiRosterContentProvider. I'm working on enhancing this view right now...and if others want to help with this please say so and I'll coordinate (it's a brand new view class and we can add whatever we want to this new roster viewer).

So there would be no dependencies on SWT. Is this correct?

org.eclipse.ecf.presence has no UI dependencies (pure shared model). org.eclipse.ecf.presence.ui *does* have dependencies on UI code (and on org.eclipse.ecf.presence).

I see this as valuable as it increases the type of applications that can utilize the ECF presence logic.

Yes, exactly. Hopefully this will make it easier for both the UI-less usage of ECF (e.g. servers), the folks that want to create their own UI from scratch, and the programmer that wants to extend or just use the new UI in org.eclipse.ecf.presence.ui.


Back to the top