ECF Application Refactoring

Motivation

The Eclipse Communication Framework Project team's primary goal is clearly identified as providing an easy-to-use, high quality, consistent, and versatile communications API to the Eclipse Platform.

In order to better convey the features that ECF has to offer and more effectively generate initial interest in the developer audience, exemplary applications, representing rather tangible incarnations of the opportunities ECF enables, will be created to serve as fully functional showcases of ECF technologies.

Existing Items to be Rewritten/Refactored

Example Collab Application

The org.eclipse.ecf.example.collab plugin needs to undergo major refactoring work to extract common components and individual WorkbenchParts so that they can be installed separately or in bundles (similar to how users of Eclipse that just wants the JDT can get the platform+JDT binary without having to install the PDE) and used in RCP applications.

Furthermore, the Collab Application should offer different sets of plugins, semantically suitable for combination, arranged in distinct workbench perspectives.

Bug #160633 is tracking this work.

Suggested initial set of features

• Discovery of ECF generic, xmpp servers.
• Client runs ECF generic server (user decided)
• XMPP buddy list. Combine Hyperbola and ECF buddy list features
• IRC, XMPP, ECF generic chat
• Bulletin Board API
• File Transfer
• XMPP Group chat
• UI Features for presence, IM, text chat.
  • See bugs #110896, #110894, #106562, and #112599
• Open Browser Links.
  • See bug #148874
• Text input/output font control
• URL Co-browsing
• Shared Whiteboard
• Event recording and playback
• <Please add more here>

Suggested package names

• org.eclipse.ecf.ui
  • ECF generic functionalities, common connect dialog
• org.eclipse.ecf.ui.im
  • XMPP, IRC, chatting/instant messaging-related
• org.eclipse.ecf.ui.datashare
  • shared editor, whiteboard, shared code, file transfer, bulletin board
• org.eclipse.ecf.ui.services
  • remote services, publishing subscription, discovery
• <Please feel free to add more or change the names since nothing is yet set in stone.>

Planned Items

Lightweight RCP Applications

In addition to the already existing, workbench-centric and fairly complete Example Collab Application, a new series of RCP-based applications are planned. The reasoning behind this new set of standalone exemplary implementations is manifold:

• less overwhelming experience to support wider adoption and improve on reluctance to try threshold
• increased focus on a small set of features to better present them
• clearer definition of target audience and application domain to increase user/developer interest

Given the existing ECF functionality and desire for the first venture into RCP example application land being of broad appeal, a multi-protocol ECF instant messenger seems quite feasible.

[More info on the IM client is to follow during the course of the 3rd October week ..., please feel free to add suggestions of your own.]

Requirements and Design Ideas

In my opinion there should be two views that would allow 3rd party plugins to contribute actions to. First one should be the Roster/Buddy list, and second one should be the Collaboration view where all the chatting and user interaction would be happening.

Buddy list should always show list of buddies (no matter if connected or offline), and should allow add/remove buddies either manually or programmatically (i.e. sync up with remote buddy list like it is now with gtalk). Roster may also allow to group/tag users (i.e. per IM server, or per linked project) and somehow allow other plugins to show additional info (e.g. mylar could show what task user is working on and stuff like that). And of course all the buddy attributes should be available to the plugins, so they could use registered buddies for their own needs (i.e. complete users in Mylar editors and or show if user from CC list is online).

Collaboration view should not bring up any popup windows, but may instead use multiple instances (like Console view), nested tabs (I think log viewer plugin does that) or dropdowns (like Console or Team Sync view) to separate different conversations. Personally I think tabs would work best. Then you could add some notification to the Workbench status bar (similar to progress indication for type hierarchy search) that would allow to see new messages without activating Collaboration view and quickly jump into those messages. I could continue, but

this is for a start. -- Eugene Kuleshov

I think with this new UI stuff, ECF should try to:

• provide reusable UI components
• create RCP application(s) based on those components
• create an IDE integration layer based on those components (for integrating with Mylar etc.)

These three might overlap, but I think designing with that separation in mind would help a lot -- Erkki Lindpere

If the buddy list always shows all buddies — offline and online — the visual representation should distinguish between the two. E.g. the offline buddies should be shown grayed out, etc. -- Jay Batson