[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] ECF Publish/Subscribe mechanism
- From: "Carl Cook" <carl@xxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 5 Jul 2006 15:07:20 +1200
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=GvEYAqIcbYp6PYRfNSuAPF+EANCDQD7NSzWqWQduukreNS82nGHZ349Ypy1csZHKowqSbG46Kd8bM41ryZZUEBrR9A6QSPCRYQCFw2ayy5tQv90yqkm/jAa+ZjJ5snBNMPHZwGKWy/wEgcVpDMzzzob7WTiwYNle0Vo8M2b8Q4M=
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.