Hi Peter,
I agree with what you are saying about cutting down broadcasts of
change events to only those who subscribe.
I have implemented a similar API in the past, and scalability is
severely limited if you adopt a "broadcast to all" approach.I
I know that you have side-lined being able to edit shared resources
for the meantime, but I really feel that the ability to edit resources
must be taken into account from the start.
In my implementation, here is what I do (for a client-server,
distributed MVC approach). This might be of use to you (although it is
at quite a lower level than the content of your previous email)..
but I know it definitely works as a stategy for distributed
sharing/editing.
* The server maintains the authoritative source of all shared data
* The server processes change requests from clients sequentially
(i.e. within a single thread)
* Change requests must be "atomic units", i.e. individual
keystrokes, cursor position changes or mouse clicks (not a
series of such elements)
* All clients register with the server as they join, and the
latest version of shared data is immediately sent to each client
* Any changes to data that clients make are sent to the server in
terms of a request
* The server makes the change to the central resource, and then
sends out the change requests
* All clients then update their local copy of the model/view,
based on any change feedback from the server
This approach guarantees protection from deadlocks, and a consistent
state between all clients and the server. It does not, however,
provide any floor-control policies, which may cause an issue for
people editing the same line of text/component with a graph, etc. In
this case, I simply added additional user-awareness mechanisms, such
as telecursors, smart-feedback, etc.
For fine-grained real-time editing (such as text editing), a client
might have to queue several change requests within the UI (such as
multiple keystrokes within a shared text editor), and then send these
off to the server one-by-one. As long as the latency between the
client and server is within normal bounds, there is no noticeable
"jitter" on the client.
I used the above approach for implemented a real-time text editor for
Java code, which worked fine for small groups of developers (teams of
up to five) working on a small set of files collaboratively. I am
happy to donate my code actually, if need be, but this would then need
to be converted to the ECF framework, which would be a considerable task.
Please get back to me on whether or not this helps your intentions...
I am very interested in this area of ECF.
Thanks,
~Carl.
------------------------------------------------------------------------
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev