[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Optionally Using ECF Functionality
|
Hi Ken,
Ken Gilmer wrote:
Scott,
No. BTW, do you mean a chat view as in the IM chat, or the example
collab chat?
This is the ID of the view we want to use:
org.eclipse.ecf.presence.ui.chatroom.ChatRoomManagerView
I'd prefer not to add ECF dependencies into our build system. It is
complex enough already...
Understood...complex build systems seem to be the way of the plugin
world.
But I'm not sure that even an ECF extension point would really help
you with avoiding this, as if I'm reading you right you probably want
to include ECF plugins/bundles in the version of you product targeted
for Eclipse 3.3, but not for versions targeted for Eclipse 3.2 or
earlier...is that right?
Well, we don't want to necessarily include ECF at all. If a user opts
in and installs ECF we'd like communication features in our
perspective. Essentially we'd like to detect an extension point at
runtime, query for the presence of the necessary ECF plugins, and via
the schema create the ECF view in our perspective. The extension
point schema would allow us to create the view without having to
reference ECF classes (avoiding the build and tight coupling issue.)
Is this for an Eclipse-based app or something else (e.g. an RCP app)?
Currently we have some ECF boilerplate code that creates an IRC
container and passes that to the chatroom view. I see no reason why
this could not be encapsulated into ECF. Thoughts?
Well, I suppose that we could add an extension point that by schema
passed a container name (e.g. ecf.irc.irclib), targetID (e.g.
irc://username@hostname:port/channel), and (opt) password onto a class
that created the container, connected to it, and displayed the
ChatRoomManagerView. The bot API already has an extension point
somewhat like this...(org.eclipse.ecf.presence.bot.chatRoomRobot).
I'm not immediately sure where such an extension point should go,
however...and it's not clear to me how the view that was opened would
'know' which perspective (yours) that it should display in (i.e. without
some 'advisor' interface...which would result in an ECF code dependency
[intf] as well).
So I'm not against it, but I don't yet know how (or where) exactly to
implement such an extension point.
Scott
