[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ECF Publish/Subscribe mechanism

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