| RE: [ecf-dev] Shared Editor Workflow Proposal |
---------------------------------------------------------------------------------
Gary
Pollice
gpollice@xxxxxxxxxx
Professor of
Practice, Computer Science
gpollice@xxxxxxxxxxxx (alternate)
Worcester Polytechnic Institute
Office: 508-831-6793
100 Institute
Road
Mobile: 978-798-0019
Worcester, MA
01609-2280
<http://www.cs.wpi.edu/~gpollice/>
From: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ken Gilmer
Sent: Saturday, April 22, 2006 11:53 AM
To: ecf-dev@xxxxxxxxxxx
Subject: [ecf-dev] Shared Editor Workflow Proposal
Hi!
Now that we've got (albeit inefficient and overly simplified) shared editor code that validates the concepts, what thoughts out there are there for:
1. how an shared editor session is created (initialized)
2. how a session is joined
3. how a session (client instance) disconnects
4. how a session (group) disconnects (is any peer able to terminate session, or only creator?)
Just as somewhere to start, what about:
1. "Initiate shared session" or "Share editor" action attached to Package Explorer view for an IResource under "team".
a. Assumption being ECF connection (provider, connection parameters,etc. are defined in a ECF preference page in preferences.
b. If the container creation is successful, what useful visual indicator can we use such that use knows a given editor is shared? (can we decorate or override the image associated with an editor?, what about using the status bar?, or simply changing the text of the editor tab to "file1.txt (shared)")
c. At an ECF level, this would create a container for available shared editor sessions. This would serve as a simple "presence" container. (Should we utilize the existing presence plugin? What other options are there?) In the future this container could handle things like authentication, etc..
2. A new workbench INewFileWizard wizard named "Connect to shared editor" or "Shared editor session" is defined. A user would then create the shared file as any other file type. In this model, I see all peers except the session creator to have "temporory" copies of the shared file. So only for the creator does the file map to a "real" file in a project. I think this is the safest/simplest way of keeping Bad Things from happening. It is then up to the creator to approve any changes and commit them to a content repository. Again this shared editor session file wizard would utilized ECF connection metadata from a preference page (maybe the user should enter it in the wizard?) The wizard would consist of a table of all existing shared editor instances. This information comes from the ECF container created in 1.c. The user selects a session, and a new editor opens with a volatile copy of the IDocument model.
3. Editing happens. ECF chat/VOIP/whatever is used in combination perhaps for discussion while shared editing is occurring. "Jane, what do you think about this interface instead..." (Another approach would be to initiate a shared editor session from a different type of ECF communication. chat, etc.. This might be handled by dragging a file into an ECF chat window. That action would execute the same action connected to the team menu.)
4. Any client except creator, by closing the editor kills their connection to the container. The editor is never dirty. There is are no additional actions required for this functionality.
5. The creator client editor is dirty upon first edit. It is the responsibility of the creator to save the file to disc, or reject changes by closing without saving. There is are no additional actions required for this functionality.
Thoughts? This perspective is from "shared editor out". I'm interested in a more holistic perspective also. IMHO, I do feel that setting ECF connection parameters once (per perference page) is better than setting them per session. I think that teams using shared editors will use a consistent ECF provider/connection, and using shared editing is more usable when not having to mess with connection data each time a session is created/joined.
thanks
ken