| <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| <title>eclipse communication framework plan</title> |
| <link rel="stylesheet" href="http://www.eclipse.org/default_style.css" type="text/css"> |
| </head> |
| <body bgcolor="#FFFFFF"> |
| </table> |
| <table border=0 cellspacing=5 cellpadding=2 width="100%"> |
| <tbody> |
| <tr> |
| <td width="69%" class="bannertext"><font class="indextop style2">eclipse communication framework<br>plan</font> |
| <br><br> |
| <font class="indexsub">an eclipse technology subproject</font> |
| </td> |
| <td width="31%"><div align="center"><img src="../images/Idea.jpg" width="120" height="86" |
| hspace="50" align="middle"></div></td> |
| </tr> |
| </tbody> |
| </table> |
| <table border=0 cellspacing=5 cellpadding=2 width="100%" > |
| <tr> |
| <td align=left valign=top bgcolor="#0080C0"> |
| <font color="#FFFFFF" face="Arial,Helvetica"> |
| <b>ECF Plan</b> |
| </font> |
| </td> |
| </tr> |
| <tr> |
| <td> |
| <p>Further expansion of the ECF project milestones will be available in the future.</p> |
| <p>We plan to follow a milestone based delivery schedule with incremental |
| progress visible in each milestone. Below is our initial cut toward defining |
| the major ECF project milestones.</p> |
| <strong>Note:</strong> see <a href="documentation.html">ECF Documentation</a> for description of ECF capability. |
| </td> |
| </tr> |
| <a name="ecf_milestones"></a> |
| <td align=left valign=top bgcolor="#0080C0"> |
| <font color="#FFFFFF" face="Arial,Helvetica"> |
| <b>Milestone 1 - February 1, 2005</b> |
| </font> |
| </td> |
| </tr> |
| <tr> |
| <td> |
| <p>For our initial milestone we will be concentrating on deliverying 1) a |
| stable, well-documented core API; 2) a set of useful communications and |
| collaboration features. For the application features, we will be concentrating |
| on a combination of asynchronous and synchronous collaboration capabilities. |
| See the <a href="#feature_developement_plan">ECF Feature Development Plan</a>.</p> |
| <b>Application Features</b> |
| <ul> |
| <li><img border="0" src="images/plan/progress.gif" width="14" height="5"> |
| <a href="#seto">Shared Editor for Team Outlining</a></li> |
| <li><img border="0" src="images/plan/investigation.gif" width="14" height="14"> |
| <a href="#prss">Project RSS</a></li> |
| <li><img border="0" src="images/plan/progress.gif" width="14" height="5"> |
| <a href="#im">Instant Messaging/User Presence/Chat</a></li> |
| <li><img border="0" src="images/plan/progress.gif" width="14" height="5"> |
| <a href="#filesharing">File Sharing</a></li> |
| <li><img border="0" src="images/plan/progress.gif" width="14" height="5"> |
| <a href="#urlsharing">URL Sharing</a></li> |
| </ul> |
| <b>Core Features</b> |
| <ul> |
| <li><img border="0" src="images/plan/finished.gif" width="14" height="14"> |
| <a href="http://www.eclipse.org/ecf">Initial API Definition and Implementation</a> |
| <li><img border="0" src="images/plan/progress.gif" width="14" height="5"> |
| <a href="http://www.eclipse.org/ecf/documentation.html">Overview Documentation, API Documentation, and Example Applications</a></li> |
| <li> |
| <a href="#core_framework_features">Provider Implementations</a></li> |
| <li><img border="0" src="images/plan/investigation.gif" width="14" height="14"> |
| <a href="#core_framework_features">ECF-native provider</a></li> |
| <li><img border="0" src="images/plan/progress.gif" width="14" height="5"> |
| <a href="#xmpp_jabber">XMPP/Jabber</a></li> |
| </ul> |
| </td> |
| </tr> |
| <tr> |
| <td align=left valign=top bgcolor="#0080C0"> |
| <font color="#FFFFFF" face="Arial,Helvetica"> |
| <b>Milestone 2 Plan - May 1, 2005</b> |
| </font></td> |
| </tr> |
| <tr> |
| <td> |
| <p>Deploy initial set of demonstration applications upon the communications |
| framework. Finalize APIs and extension points for identity/authentication, asynch |
| communication, and component abstraction after community usage and review.</p> |
| <b>Application Features</b> |
| <ul> |
| <li><img border="0" src="images/plan/investigation.gif" width="14" height="14"> |
| <a href="#calendar">Project Calendar</a></li> |
| <li><img border="0" src="images/plan/progress.gif" width="14" height="5"> |
| Application Sharing</li> |
| <li><img border="0" src="images/plan/investigation.gif" width="14" height="14"> |
| Shared Whiteboard</li> |
| <li><img border="0" src="images/plan/progress.gif" width="14" height="5"> |
| Team Remote Control of Eclipse</li> |
| <li><img border="0" src="images/plan/investigation.gif" width="14" height="14"> |
| Team Debugging</li> |
| </ul> |
| <b>Core Features</b> |
| <ul> |
| <li> |
| <a href="#core_framework_features">Provider Implementations</a></li> |
| <li><img border="0" src="images/plan/progress.gif" width="14" height="5"> |
| <a href="#jms">JMS</a></li> |
| <li><img border="0" src="images/plan/investigation.gif" width="14" height="14"> |
| <a href="#bit_torrent">BitTorrent</a></li> |
| <li><img border="0" src="images/plan/investigation.gif" width="14" height="14"> |
| <a href="#sip_simple">SIP</a></li> |
| </ul> |
| </td> |
| </tr> |
| <tr> |
| <td align=left valign=top bgcolor="#0080C0"> |
| <font color="#FFFFFF" face="Arial,Helvetica"> |
| <b>Milestone 3 Plan - Q3 2005</b> |
| </font></td> |
| </tr> |
| <tr> |
| <td> |
| <p>Deliver additional demonstration applications, and a broader set of user-level |
| features. Finalize APIs for component model, extension points, and security. |
| Provide working, integrated Eclipse applications for instant messaging/chat, |
| file sharing, data/voice conferencing, and shared debugging.</p> |
| </td> |
| </tr> |
| <tr> |
| <td align=left valign=top bgcolor="#0080C0"> |
| <font color="#FFFFFF" face="Arial,Helvetica"> |
| <b>Milestone 4 Plan - Q4 2005</b> |
| </font> |
| </td> |
| </tr> |
| <tr> |
| <td> |
| <p>Revise and improve demonstration applications, update infrastructure plugin |
| APIs in response to community usage and feedback. Provide demonstration |
| application with Eclipse Modeling Framework-based shared model creation and editing. |
| </p> |
| </td> |
| </tr> |
| <tr> |
| <td align=left valign=top bgcolor="#0080C0"><b><font color="#FFFFFF" face="Arial,Helvetica"> |
| ECF Plan Legend</font></b></td> |
| </tr> |
| <tr> |
| <td> |
| <ul> |
| <li><b><font color="#FFFFFF" face="Arial,Helvetica"> |
| <img border="0" src="images/plan/finished.gif" width="14" height="14"> </font></b> |
| = item is finished</li> |
| <li> |
| <img border="0" src="images/plan/progress.gif" width="14" height="5"> = |
| item is under development</li> |
| <li> |
| <img border="0" src="images/plan/investigation.gif" width="14" height="14"> |
| = item is under investigation.</li> |
| </ul> |
| </td> |
| </tr> |
| <tr> |
| <td align=left valign=top bgcolor="#0080C0"><b><font color="#FFFFFF" face="Arial,Helvetica"> |
| <a name="feature_developement_plan">ECF Feature Development Plan</a></b></td> |
| </tr> |
| <tr> |
| <td> |
| <p>ECF has at least two critical target user groups: plugin developers and |
| user teams. Plugin developers will use the framework to build their |
| applications above ECF, while user teams will use the ECF applications |
| for doing their daily individual and team work.</p> |
| <p>These two groups can be broken down further into sub-groups. See |
| <a href="#ecf_plugin_developers">Plugin Developers</a> and |
| <a href="#user_teams">User Teams</a> for descriptions of these sub-groups.</p> |
| <p>In order to create both user team added value and plugin developer added |
| value we propose 3 'feature vectors' for ECF applications: '<b>asynchronous |
| communications features</b>', '<b>synchronous communications features</b>' and |
| '<b>core framework features</b>'.These vectors will allow the ECF team to:</p> |
| <ol> |
| <li>Define an initial sequence of ECF features to design/implement for each milestone release</li><br> |
| <li>Plan the milestone-based implementation/delivery of features</li><br> |
| <li>Communicate this plan publicly to the ECF plugin developer community</li><br> |
| <li>Receive continuous feedback about feature importance from the community</li><br> |
| <li>Receive feedback about desired featured sequencing from the community</li><br> |
| <li>Coordinate ECF committers on tasks and dependencies</li><br> |
| <li>Allow the community to participate in an open development process</li><br> |
| <li>Allow us on the ECF team to easily coordinate and build upon each other's ideas</li> |
| </ol> |
| <p>Below are listed a number of features for each of the three categories of |
| 'asynchronous', 'synchronous', and 'core framework features'.</p> |
| <a href="#ecf_milestones"><i>back to ECF Milestones</i></a> |
| |
| <h4>Asynchronous Features</h3> |
| <p>ECF needs some innovative collaboration features for user teams to show off |
| the general power of the framework. Given Eclipse's power as a generic tool |
| integration framework, we think we should focus on shared model creation and editing.</p> |
| <p>What do we mean by 'shared model and editing'? We mean using Eclipse to create |
| and persist, and ECF to share all the models and documents that are created in a |
| typical software development project: e.g. feature lists, design docs, development |
| plans, frameworks, test cases, prototypes, design (e.g. UML) models, design |
| justification, use cases, source code, api documentation, user documentation, |
| tools, technology assessments, etc.</p> |
| <p>ECF can provide a general way for *all* team artifacts to be shared |
| <b>appropriately</b> among communities of interest. Further, ECF can support the |
| team creation and editing of artifacts specifically in it's appropriate |
| context...given the team culture, the organizational structures and processes, the |
| type of project, the roles of the various team member, and the project function of |
| the artifact.</p> |
| <p>ECF can provide team sharing of structured models. ECF can ultimately be able |
| to support the real-time or asynchronous sharing of arbitrary models, among |
| appropriate team members, as well as the serialization and synchronization of |
| those shared models.</p> |
| <p>Using technologies like EMF for model creation and transformation, XMI for |
| model serialization, and SDO for persistence <font color="#000000">and incremental |
| synchronization</font>, we should be able to focus ECF's added value in the |
| dynamic distribution and synchronization of models among team members, as |
| appropriate to the team, the project, and the processes in use.</p> |
| <hr><a name="asynchronous_features_table"></a> |
| <table border=0 cellpadding=2 cellspacing=3> |
| <col width=130> |
| <col width=280> |
| <col width=60> |
| <col width=400> |
| <tr> |
| <td valign="bottom"><b>Asynchronous<br><u>Feature Name</u></b></td> |
| <td valign="bottom"><u><b>Description</b></u></td> |
| <td valign="bottom"><b>Delivery<br><u>Target</u></b></td> |
| <td valign="bottom"><u><b>ECF Team Comments</b></u></td> |
| </tr> |
| <tr> |
| <td valign="top"><a href="#shared_editor_team_outlining">Shared Editor for Team Outlining (SETO)</a></td> |
| <td valign="top"><a name="seto"></a>A Shared Editor for Team Outlining (SETO). Allow team members to |
| create team-shared outlines, and associate tasks and individual with project |
| features for agile project planning</td> |
| <td valign="top" align="center">M1</td> |
| <td valign="top">These are really two smaller features: 1) shared tasks and 2) |
| project features. UI will have integration with Eclipse's TaskList |
| view. Use ecore model to represent types and relations</td> |
| </tr> |
| <tr> |
| <td valign="top"><a href="#project_syndication">Project Syndication (PRSS)</a></td> |
| <td valign="top"><a name="prss"></a>RSS Syndication of Project-Specific News and Events for a 'Project Dashboard'</td> |
| <td valign="top" align="center">M1</td> |
| <td valign="top">Need to identify events/information channels -- anything |
| that changes outside of one's workbench session may qualify (for "subscription"; |
| the converse applies for "publication").</td> |
| </tr> |
| <tr> |
| <td valign="top"><a href="#project_calendar">Project Calendar</a></td> |
| <td valign="top"><a name="calendar"></a>Dynamically updating project calendar, with team events, milestones, and appropriate individual events</td> |
| <td valign="top" align="center">M2</td> |
| <td valign="top"> This could also be done using EMF; we can start by |
| creating the model and integrating with calendar UI</td> |
| </tr> |
| <tr> |
| <td valign="top"><a href="#eclipse_trust_framework">Eclipse Trust Framework Integration</a></td> |
| <td valign="top">Use of ETF structures to support the management of |
| personal information, the establishment and enforcement of trusted relationships</td> |
| <td valign="top" align="center">1.0</td> |
| <td valign="top"> </td> |
| </tr> |
| </table> |
| <hr><a href="#ecf_milestones"><i>back to ECF Milestones</i></a> |
| |
| <h4>Synchronous Features</h4> |
| <p>The synchronous features will provide some 'traditional' real-time collaboration |
| functionality for teams of end-users. These features will not be intended to represent |
| a complete application, but rather present a sufficient set of features that teams |
| will be able to try/use and build upon the features provided.<p> |
| <hr><a name="synchronous_features_table"></a> |
| <table border=0 cellpadding=2 cellspacing=3> |
| <col width=130> |
| <col width=280> |
| <col width=60> |
| <col width=400> |
| <tr> |
| <td valign="bottom"><b>Synchronous<br><u>Feature Name</u></b></td> |
| <td valign="bottom"><u><b>Description</b></u></td> |
| <td valign="bottom"><b>Delivery<br><u>Target</u></b></td> |
| <td valign="bottom"><u><b>ECF Team Comments</b></u></td> |
| </tr> |
| <tr> |
| <td valign="top"><a name="im"></a>Instant Messaging<br>See <a href="#chat_use_cases">Chat Use Cases<a></td> |
| <td valign="top">Text Messaging between two users</td> |
| <td valign="top" align="center">M1</td> |
| <td valign="top">Already present in Composent client. Needs some UI redesign and feature enhancement</td> |
| </tr> |
| <tr> |
| <td valign="top">User Presence</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M1</td> |
| <td valign="top">Already present in Composent client. Needs some UI redesign</td> |
| </tr> |
| <tr> |
| <td valign="top">Group Chat</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M1</td> |
| <td valign="top">Already present in Composent client. Needs some UI redesign andfeature enhancement</td> |
| </tr> |
| <tr> |
| <td valign="top"><a name="filesharing"></a>File Sharing</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M1</td> |
| <td valign="top">Already present in Composent client</td> |
| </tr> |
| <tr> |
| <td valign="top"><a name="urlsharing"></a>URL Sharing</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M1</td> |
| <td valign="top">Already present in Composent client</td> |
| </tr> |
| <tr> |
| <td valign="top">Application Sharing</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M2</td> |
| <td valign="top">Already present in Composent Windows client (for sending)</td> |
| </tr> |
| <tr> |
| <td valign="top">Shared Whiteboard</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M2</td> |
| <td valign="top">Could use Eclipse SWT example drawing application for UI</td> |
| </tr> |
| <tr> |
| <td valign="top">Remote Control of Eclipse</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M2</td> |
| <td valign="top">Limited support available in Composent client</td> |
| </tr> |
| <tr> |
| <td valign="top">Team Debugging</td> |
| <td valign="top">Team Remote Control and Display of Debugging session and/or sessions</td> |
| <td valign="top" align="center">M2</td> |
| <td valign="top"> </td> |
| </tr> |
| <tr> |
| <td valign="top">Remote Jukebox</td> |
| <td valign="top">Remote control of media player</P></td> |
| <td valign="top" align="center">M3</P></td> |
| <td valign="top"> </td> |
| </tr> |
| <tr> |
| <td valign="top">VOIP</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">1.1</td> |
| <td valign="top">Need to select VOIP protocol and server implementation</td> |
| </tr> |
| <tr> |
| <td valign="top">Voice Conferencing</td> |
| <td valign="top">Could be either VOIP-based or POTs-based</td> |
| <td valign="top" align="center">1.1</td> |
| <td valign="top"> </td> |
| </tr> |
| <tr> |
| <td valign="top">Pt2Pt Video</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">1.2</P></td> |
| <td valign="top"> </td> |
| </tr> |
| <tr> |
| <td valign="top">Video Conferencing</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">1.2</td> |
| <td valign="top"> </td> |
| </tr> |
| </table> |
| <hr><a href="#ecf_milestones"><i>back to ECF Milestones</i></a> |
| |
| <h4><a name="core_framework_features"></a>Core Framework Features</a></h4> |
| <p>One goal of provided an Eclipse-based framework is to allow interoperability |
| between Eclipse-based communications interfaces and other communications systems |
| (e.g. phones, PDAs, other PC-based apps, cross-platform, etc). With the aid of |
| open standards and open implementations of common protocols, we will look to \ |
| support a number of existing communications APIs</p> |
| |
| <hr> |
| <table border=0 cellpadding=2 cellspacing=3> |
| <col width=130> |
| <col width=280> |
| <col width=60> |
| <col width=400> |
| <tr> |
| <td valign="bottom"><b>Core Framework<br><u>Feature Name</u></b></td> |
| <td valign="bottom"><u><b>Description</b></u></td> |
| <td valign="bottom"><b>Delivery<br><u>Target</u></b></td> |
| <td valign="bottom"><u><b>Comments</b></u></td> |
| </tr> |
| <tr> |
| <td valign="top"><a name="xmpp_jabber">XMPP/Jabber</a></td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M1</td> |
| <td valign="top">Probably be able to use <a href="http://www.jivesoftware.org/smack/">Smack API</td> |
| </tr> |
| <tr> |
| <td valign="top"><a name="composent"></a>Composent</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M1</P></td> |
| <td valign="top"><a href="http://www.composent.com/">http://www.composent.com</a></td> |
| </tr> |
| <tr> |
| <td valign="top"><a name="jms">JMS (Java Messaging Service)</a></td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M2</td> |
| <td valign="top">Apache-Licensed JMS Implementation: <a href="http://www.activemq.org/">ActiveMQ</a></td> |
| </tr> |
| <tr> |
| <td valign="top"><a name="bit_torrent">BitTorrent<a></td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M2</td> |
| <td valign="top">Java-Based open source candidate implementation: <a href="http://azureus.sourceforge.net/">Azureus</a></P></td> |
| </tr> |
| <tr> |
| <td valign="top"><a name="sip_simple">SIP/SIMPLE</a></td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M3</P></td> |
| <td valign="top">Java-based open source implementation from NIST. Possibly get corporate assistance</td> |
| </tr> |
| <tr> |
| <td valign="top">Internet Relay Chat</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M3</td> |
| <td valign="top"> </td> |
| </tr> |
| <tr> |
| <td valign="top">SOAP</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M3</td> |
| <td valign="top"> </td> |
| </tr> |
| <tr> |
| <td valign="top">ML-RPC</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M3</td> |
| <td valign="top"> </td> |
| </tr> |
| <tr> |
| <td valign="top">JXTA</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M4</td> |
| <td valign="top"> </td> |
| </tr> |
| <tr> |
| <td valign="top">Jini</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M4</td> |
| <td valign="top"> </td> |
| </tr> |
| <tr> |
| <td valign="top">JavaGroups</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">1.0</td> |
| <td valign="top"><a href="http://www.jgroups.org/">http://www.jgroups.org</a></td> |
| </tr> |
| </table> |
| <hr><a href="#ecf_milestones"><i>back to ECF Milestones</i></a> |
| |
| <h4>Security</h4> |
| <hr><table border=0 cellpadding=2 cellspacing=3> |
| <col width=130> |
| <col width=280> |
| <col width=60> |
| <col width=400> |
| <tr> |
| <td valign="bottom"><b>Security<br><u>Feature Name</u></b></td> |
| <td valign="bottom"><u><b>Description</b></u></td> |
| <td valign="bottom"><b>Delivery<br><u>Target</u></b></td> |
| <td valign="bottom"><u><b>Comments</b></u></td> |
| </tr> |
| <tr> |
| <td valign="top">Support for remote classloading in serialization</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M2</td> |
| <td valign="top"> </td> |
| </tr> |
| <tr> |
| <td valign="top">Eclipse Trust Framework Full Integration</td> |
| <td valign="top"> </td> |
| <td valign="top" align="center">M3</td> |
| <td valign="top"> </td> |
| </tr> |
| <tr> |
| <td valign="top">Integration with Equinox/JAAS</td> |
| <td valign="top"> </td> |
| <td valign="top"align="center">1.0</td> |
| <td valign="top"> </td> |
| </tr> |
| </table> |
| <hr><a href="#ecf_milestones"><i>back to ECF Milestones</i></a> |
| <tr> |
| <tr> |
| <td align=left valign=top bgcolor="#999999"><b><font color="#FFFFFF" face="Arial,Helvetica"> |
| <a name="ecf_plugin_developers">ECF Plugin Developers</a></font></b></td> |
| </tr> |
| <tr> |
| <td valign="top"> |
| <b>There are four major plugin developer groups relevant for ECF</b> |
| <ol> |
| <li><b>providers</b>: Plugin developers that implement existing or new |
| communications protocols and supply these protocols as provider modules |
| underneath the ECF APIs. The primary value created by these developers is |
| one of interoperability. That is, with multiple provider implementations, |
| other plugin developers and users can allow their Eclipse/ECF-based |
| applications interoperate with other systems (e.g. IM systems, file sharing |
| systems, web-based APIs, etc).</li><br> |
| <li><b>component builders</b>: Plugin developers who implement generic |
| component-level features for communications features (e.g. file sharing, chat, |
| shared whiteboard, team RSS, etc). These developers provide application-level |
| features that can be combined into full ECF-based applications. Their primary |
| value is to provide reusable communications components to application designers.</li><br> |
| <li><b>tool integrators</b>: Plugin developers who integrate existing and/or |
| new tools with ECF to create some new application-level value for an individual |
| or work team. For example, the integration of ECF with EMF/SDO creates an ability |
| for applications to create and share models among multiple users. Their primary |
| value comes from taking features and technologies and combining them into new, |
| more-useful applications and features.</li><br> |
| <li><b>ui builders/integrators</b>: Plugin developers who create and/or integrate |
| UIs for user access to features exposed via other plugins. Their primary value is |
| in creating improved user interfaces, by design or by integration.</li> |
| </ol> |
| <a href="#feature_developement_plan"><i>back to ECF Feature Development Plan</i></a> |
| </td> |
| <tr> |
| <tr> |
| <td align=left valign=top bgcolor="999999"><b><font color="#FFFFFF" face="Arial,Helvetica"> |
| <a name="user_teams">User Teams</a></font></b></td> |
| </tr> |
| <tr> |
| <td valign="top"> |
| <p>The ECF plugin users are intended to be teams of software developers, typically |
| working together on some identified project. Here are some features of these teams |
| that can be used to identify the communications needs at the user level.</p> |
| <h4>Team Distribution</h4> |
| <ul> |
| <li>Co-Located</li> |
| <li>Distributed</li> |
| <li>U.S.</li> |
| <li>International</li> |
| </ul> |
| <h4>Team Size</h4> |
| <ul> |
| <li>Small (<15)</li> |
| <li>Med (>15)</li> |
| <li>Large (> 50)</li> |
| </ul> |
| <h4>Varied Roles?</h4> |
| <ul> |
| <li>Role Specific Team (all developers)</li> |
| <li>Multiple Roles (dev, testing, mgmt, arch, etc)</li> |
| </ul> |
| <h4>Team Type</h4> |
| <ul> |
| <li>Hierarchical</li> |
| <li>Group</li> |
| <li>Network</li> |
| </ul> |
| <h4>Team Function</h4> |
| <ul> |
| <li>Software Development |
| <li>Manufacturing |
| <li>Management |
| <li>Educational |
| <li>Entertainment</li> |
| <li>Relational |
| <li>Political</li> |
| </ul> |
| <h4>Surrounding Organization and Culture</h4> |
| <ul> |
| <li>Enterprise</li> |
| <li>ISV</li> |
| <li>Governmental</li> |
| <li>Geographic Community</li> |
| <li>Open Source</li> |
| </ul> |
| <a href="#feature_developement_plan"><i>back to ECF Feature Development Plan</i></a> |
| </td> |
| <tr> |
| <td align=left valign=top bgcolor="999999"><b><font color="#FFFFFF" face="Arial,Helvetica"> |
| <a name="shared_editor_team_outlining">Shared Editor for Team Outlining</a></font></b></td> |
| </tr> |
| <tr> |
| <td valign="top"> |
| <p>The focus for ECF M1 should be on supporting the sharing of information critical |
| to distributed development team effectiveness. One project-team-critical sort of |
| information is feature and tasks planning. Ideally, in XP-like development processes, |
| there is a tight relationship between the definition of the user-required features |
| for a product, the definition and scoping of tasks necessary to build those features, |
| and the coordination of the people that are to perform those tasks. These relationships |
| optimally need to be defined/constructed by team members.</p> |
| <p>Simple outliners and todo lists are a common tool for people to organize their personal tasks.</p> |
| <p>As an initial example of an asynchronous team communication application, we should |
| create a multi-user outliner that allows team members to jointly create and edit |
| feature lists, associated tasks, task dependency relationships, and individual and |
| team sub-tasks.</p> |
| <p>Such an outliner could start with the simplifying assumption that everything is |
| related hierarchically, and create an interface that allows team members to see (but |
| not edit) the organizations created by other team members. Then, the hierarchy |
| assumption could be relaxed, and the access controls to information created by a |
| given user may also be relaxed.</p> |
| <a href="#asynchronous_features_table"><i>back to Asynchronous Feature table</i></a> |
| </td> |
| <tr> |
| <tr> |
| <td align=left valign=top bgcolor="999999"><b><font color="#FFFFFF" face="Arial,Helvetica"> |
| <a name="project_syndication">Project Syndication</a></font></font></b></td> |
| </tr> |
| <tr> |
| <td valign="top"> |
| <strong><em>Under construction...</em></strong> |
| <br><br> |
| <a href="#asynchronous_features_table"><i>back to Asynchronous Feature table</i></a> |
| </td> |
| </tr> |
| <tr> |
| <td align=left valign=top bgcolor="999999"><b><font color="#FFFFFF" face="Arial,Helvetica"> |
| <a name="project_calendar">Project Calendar</a></font></b> |
| </td> |
| </tr> |
| <tr> |
| <td valign="top"> |
| <strong><em>Under construction...</em></strong> |
| <br><br> |
| <a href="#asynchronous_features_table"><i>back to Asynchronous Feature table</i></a> |
| </td> |
| <tr> |
| <tr> |
| <td align=left valign=top bgcolor="999999"><b><font color="#FFFFFF" face="Arial,Helvetica"> |
| <a name="eclipse_trust_framework">Eclipse Trust Framework (ETF) Integration</a></font></b></td> |
| </tr> |
| <tr> |
| <td valign="top"> |
| See <a href="http://www.eclipse.org/proposals/etf/index.html">Eclipse Trust Framework proposal</a> |
| <br><br> |
| <a href="#asynchronous_features_table"><i>back to Asynchronous Feature table</i></a> |
| </td> |
| <tr> |
| <tr> |
| <td align=left valign=top bgcolor="999999"><b><font color="#FFFFFF" face="Arial,Helvetica"> |
| <a name="chat_use_cases">Chat Use Cases</a></font></b></td> |
| </tr> |
| <tr> |
| <td valign="top"> |
| <p>The ECF development team is considering at least four distinct types of chat use |
| cases depending on whether GroupIDs and chat SharedObject IDs are well-known or not. |
| We have given each of the types a name suggested by the manner in which it would be |
| used. This name is not really the important issue. What's important here is the |
| combination of well-known and individualized IDs.</p> |
| <hr> |
| <h4>1. ChatRoom -- GroupID well-known, Chat SharedObject ID well-known</h4> |
| <p>In this case everyone knows a common familiar GroupID, e.g., "server.com" and joins |
| that container. They also create a SharedObject with the well-known ID, "chat". |
| This is a big space that anyone with permission to use "server.com" may enter.</p> |
| |
| <h4>2. IM -- GroupID well-known, Chat SharedObject ID individualized</h4> |
| <p>We all join a well-known container for some purpose. It doesn't have to be to chat. |
| We might have joined the container for the purpose of learning about people's |
| online status. Then, you decide that you would like to chat with someone, but don't |
| want to go to the trouble of creating a new container for that purpose. So, instead, |
| you create a ChatSharedObject, but give it a unique ID. Then, you direct some other |
| group member to create that ChatSharedObject as well. Now, we can use the chat, but |
| others are not aware of our chat and cannot participate.</p> |
| <p><u>Note</u>: The privacy afforded by this approach depends somewhat on whether |
| getSharedObjectIDs returns all the IDs known at the container or only the ones |
| created by any user.</p> |
| |
| <h4>3. Chat Meeting -- GroupID individualized, Chat SharedObject ID well-known</h4> |
| |
| </p>This case requires two containers: one for the actual chat and one to communicate |
| the individualized GroupID of that chat.</p> |
| |
| <ol> |
| <li>We all join a well-known container that we call the Lobby. |
| Let's say it has a GroupID of "server.com/lobby" and provides some |
| way to send invitations from one user to another.</li><br> |
| <li>One user creates a new container and joins it by creating a unique |
| GroupID for the chat, e.g., "server.com/mychat". In addition, the |
| user adds a ChatSharedObject with the well-known ID, "chat".</li><br> |
| <li>This first user sends an invitation to another user via the lobby |
| to let the second user know that they are invited to the |
| "server.com/mychat" container. (Presumably, it would also be good |
| to send information about the container type, just in case we want |
| to support multiple types of meetings.</li><br> |
| <li>The second user joins the meeting by creating the appropriate chat |
| container, adding in the appropriate chat object, and joining with |
| the "server.com/mychat" GroupID.</li> |
| </ol> |
| |
| <h4>4. Whisper -- GroupID individualized, Chat SharedObject ID individualized</h4> |
| |
| <p>Let's imagine that the ChatMeeting identified above has been joined by many people |
| and we now want to support a private conversation among a subset of the participants. |
| Assuming we are too lazy to create a new container for the purpose, one user might |
| create a new chat object with an individualized ID, then, as in the IM case, they |
| would instruct another user to create the object as well.</p> |
| </p><u>Note</u>: The privacy afforded by this approach depends somewhat on whether |
| getSharedObjectIDs returns all the IDs known at the container or only the ones created |
| by any user.</p> |
| <hr> |
| <h4>Chat Use Case Considerations</h4> |
| <p>One thing the ECF development team with these use cases is to begin to tie specific |
| communication features to patterns in the use of ECF containers and shared objects. For |
| example, say that you had a 'well-known' chat, and you wanted to have a feature that |
| started a shared whiteboard with the same set of participants. Well, one way to implement |
| this would be to have the chat create a new shared object (a whiteboard component) that |
| implemented the whiteboard communications functionality (i.e. keeping the whiteboard |
| state synchronized) and the whiteboard UI. In this way, the whiteboard functionality |
| would be separable from the chat, and usable within different communications contexts. |
| The whiteboard component could even be implemented to run similarly on multiple container |
| implementations (multiple providers)...e.g. SIP or XMPP or whatever. In this way a library |
| of components could be created, implemented as shared objects (in this case), or |
| combinations of shared objects and provider implementations (less desirable from a |
| component design point of view).</p> |
| <p>In any event, we think that with a variety of use cases (these and others) and a |
| couple of functioning providers (coming very shortly), we can experiment a little bit |
| with the design of communications components, and begin to connect various features |
| with individual components or sets of components (implemented as independent shared |
| objects, shared objects with connectors, patterns of classes used by shared objects, |
| custom containers, etc).</p> |
| |
| <a href="#synchronous_features_table"><i>back to Synchronous Feature table</i></a> |
| </td> |
| <tr> |
| </table> |
| |
| </body> |
| </html> |
