[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:


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.