[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Request for suggestion about implementing a shared model

Hi Mario,

Mario Scalas wrote:
Hi all,
  I need to share a model representing a queue of pending requests in a group 
chat. Moderator should be able to approve/reject requests and modifications 
on his local model should trigger changes in remote hosts too (so users can 
see what is the state).
  Any advice on how should I implement this? Implementing the model as an 
ISharedObject or using the DataShare API? 
  

I would suggest that you stick with the DataShare API...and implement your own model and associated synchronization protocol by using IChannel.sendMessage.  Also, the datashare API is supported by several transports (e.g. xmpp, ecf generic, jms provider, etc) so this would allow you to run the same logic on a variety of implementations.

But it does sound as if there are good reasons to also consider the shared object API, as it like you want to do a fair amount with replicated state...and the shared object API is intended to make state replication and associated replica synchronization easier.

One point to appreciate:  the 'default' implementation of datashare (i.e. in plugin org.eclipse.ecf.provider.datashare) is actually implemented via a shared object...so if you like you could start by using the datashare API, and if you find that you need it or want the extra facilities provided by the shared object API, you could 'drop down' to use the shared object API directly.

Sounds like an interesting project.  Any chance that you could tell us more about it...or perhaps even make it available to other ECF users?

Note that we in ECF are going to be doing a fair amount of work on 'shared models' in the Ganymede timeframe, as we are going to be working on adding API and impl for replicating models for shared editing, and keeping them in synch as peer-based changes/editing are made.  If this is something people would like to contribute to, please let us know.

Thanks,

Scott


Thanks
Mario

  

_______________________________________________ ecf-dev mailing list ecf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/ecf-dev