[
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.
Scott
