Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ECF Publish/Subscribe mechanism 
Hi Carl,
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 and/or reused. 

--Peter

Carl Cook wrote:

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

Back to the top