Now that we've got (albeit inefficient and overly simplified) shared
editor code that validates the concepts, what thoughts out there are
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
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.