Re: [ecf-dev] Additions to org.eclipse.ecf.example.collab.editor

["Ken Gilmer" <kgilmer@xxxxxxxxx>]

>Is this what you are
suggesting?

Yes, although in interests of keeping things simple, I think:

1. Check local version with shared version
2. if same, join group
3. else if different, present yes/no dialog asking if they want to load shared version of document.

>What if you offered some/many strategies for merging?

For the first cut, I'd suggest not having any merge functionality.  All or nothing.

Would it be possible to implement a transaction across clients for a model update?  Has this already been done? 

-Ken

On 3/24/06, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

Hi Ken,

Ken Gilmer wrote:

>
> I've added more code to the action to retrieve the resource for the
> active editor.  I've also added a listener that can be attached to the
> editor.  This listener can pass events to a shared container and
> retrieve them from other clients.  I see there being two types of
> messages:
>
> 1. Editor checksum: confirm with a hash that all shared editors have
> same document (required at start of shared session)
> 2. Modification event: the string, offset, and lenght of an edit
> (passing full IDocument is not required)
>
> I think the simplest case would be that a client trying to join a
> shared session would first be required to pass a editor content hash
> value check, confirming that all editors are in sync.

Ken this sounds like an interesting idea.  So are you saying that 'late
joiners' would report what they *thought* the current state was (i.e. a
hash value of their current editor contents) and then...only if that
content doesn't match some some authoritative copy's hash...they would
engage in some further protocol to do one of several things...e.g. a)
get a full new copy of the authoritative state; b) apply some merge
strategy (maybe content specific strategy, etc).  Is this what you are
suggesting?

> This would prevent users from joining a session after edits have been
> made however.


Only if you simply rejected people who's hash didn't match the current
state.  What if you offered some/many strategies for merging?

> Another approach would be to add a thrid message type which is the
> full content of the IDocument, asking the user upon join if they'd
> like to update the editor with the shared version.

Right...you could ask the user what they would like to do (replace,
merge with one of several strategies, etc)...or you could simply apply
some heuristics to select among some merging strategies...perhaps always
falling back to simply getting a full new copy of the authoritative
state if nothing else can be done (and, of course, throwing away the
late joiner's local copy).

BTW, when I say 'authoritative state', I simply mean that *one* of the
replicas (frequently on a server, but not always) is known by all
participants to be special or 'primary'.  The ECF group
communication/shared object model *does* already include a concept of a
'primary' copy (typically where the object was actually created).  The
primary is frequently also strongly associated with persistence...and
frequently persistence is provided by a server of course...but in ECF
there is no architectural requirement that the primary exist only on
the/a server.

Scott


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev