Re: [ecf-dev] ECF Publish/Subscribe mechanism

["Carl Cook" <carl@xxxxxxxxxxxxxxxxxxxxx>]

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 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.