[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] ECF Publish/Subscribe mechanism
- From: Peter Nehrer <pnehrer@xxxxxxxxxxxxx>
- Date: Wed, 05 Jul 2006 12:32:12 -0400
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 22.214.171.124 (Windows/20060516)
thank you for your suggestions -- they're most welcome. Note that in the
current solution the master copy still broadcasts to all connected
containers, and it's up to the container to optimize this operation;
e.g., check if each target container actually has a replica with the
given ID. Alternatively, the master copy could only forward to its
current subscribers one by one, but the idea is that the to-all call
might be more efficiently implemented by the container.
I haven't considered the editing of a shared model (in this context)
yet, because it's very hard :-). I'd like to explore the idea of
allowing the client to view the whole domain as if it were local --
remote services have their replicas in the local container, and it's up
to the service to implement master/replica or inter-replica
communication. I haven't actually explored this scenario yet; in the
example, the client talks directly to the replica and different shared
objects (in the same container) don't talk to each other very much. I
suppose it's possible to extend this solution by letting different
shared models influence each other somehow (e.g., keep themselves
synchronized with respect to one another).
I'm still trying to develop the feel for the right patterns and best
practices in ECF. For example, the traditional "synchronous query" model
(whereby you invoke a method on a service and get the result in return)
doesn't work too well because of the asynchronous nature of shared
objects. It's much better to send a request and allow the target to
notify you somehow (w/out assuming that this will necessarily happen).
I agree with you that ultimately the ability to collaboratively edit a
resource is of the highest value. I think it would be fantastic if you
could donate your previous work. Do you think you could participate in
its conversion to ECF? As you know, we do have an ongoing shared editor
effort, and I wonder how much of the two solutions could be merged
Carl Cook wrote:
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
* 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.
ecf-dev mailing list