Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "ECF Application Refactoring"
(introduced notion of RCP example apps) |
m (→Motivation) |
||
| (8 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ==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''. | |
| − | The Eclipse Communication Framework 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 | + | 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=== | ===Example Collab Application=== | ||
| − | + | The org.eclipse.ecf.example.collab plugin needs to undergo major refactoring work to extract common components and individual <tt>WorkbenchPart</tt>s 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 [[Application Refactoring#Lightweight RCP Applications|RCP applications]]. | |
| − | + | ||
| − | + | ||
| − | + | Furthermore, the ''Collab Application'' should offer different sets of plugins, semantically suitable for combination, arranged in distinct workbench perspectives. | |
| + | Bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=160633 #160633] is tracking this work. | ||
| + | |||
| + | ====Suggested initial set of features==== | ||
* Discovery of ECF generic, xmpp servers. | * Discovery of ECF generic, xmpp servers. | ||
* Client runs ECF generic server (user decided) | * Client runs ECF generic server (user decided) | ||
| Line 29: | Line 20: | ||
* File Transfer | * File Transfer | ||
* XMPP Group chat | * XMPP Group chat | ||
| − | * UI Features for presence, IM, text chat. | + | * UI Features for presence, IM, text chat. |
| − | * Open Browser Links. | + | ** See bugs [https://bugs.eclipse.org/bugs/show_bug.cgi?id=110896 #110896], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=110894 #110894], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=106562 #106562], and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=112599 #112599] |
| + | * Open Browser Links. | ||
| + | ** See bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=148874 #148874] | ||
* Text input/output font control | * Text input/output font control | ||
* URL Co-browsing | * URL Co-browsing | ||
| Line 36: | Line 29: | ||
* Event recording and playback | * Event recording and playback | ||
* <Please add more here> | * <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=== | ||
| + | <div style="border: 2px solid #8E87EB; padding: 6px;"> | ||
| + | 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</div> | ||
| + | |||
| + | <div style="border: 2px solid #8E87EB; padding: 6px;"> | ||
| + | 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 | ||
| + | </div> | ||
| + | |||
| + | <div style="border: 2px solid #8E87EB; padding: 6px;"> | ||
| + | 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 | ||
| + | </div> | ||
| + | |||
| + | [[Category:Eclipse Communication Framework|Application Refactoring]] | ||
Latest revision as of 21:49, 30 March 2007
Contents
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.
- 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 KuleshovI 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