Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Additions to org.eclipse.ecf.example.collab.editor

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




Back to the top