Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] How do I share object between clients? 
Hi Hiroki,

Hiroki Kondo wrote:

Hi all!

Now I want to create a new Eclipse RCP Application.
The Application's goal is sharing schedule between participants of
group, to edit like calendar, using GEF.

So I want to replecate object between Eclipse Clients.
Now I use ecftcp protocol to share the object,
Which can I use ,IChannel or ISharedObject?
Truthfully, you can use either. In the generic provider IChannel instances are actually implemented with ISharedObjects. IChannels are simpler, so I would recommend using them. 



I think, IChannel is interface messaging protocol.
IChannel.sendMessage(byte[]) method is to share object's changes.


You can easily serialize/deserialize an object to a byte array:

ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(object);
byte [] bytes = bos.toByteArray();
ISharedObjects essentially do this for you. And on the receiving side they manage the classloading of serialized classes via the buddy-loader mechanism in Equinox. If you do the object serialization yourself via a channel, then you need to manage the classloading on deserialization yourself. 



But ISharedObject is completely to replicate object.
Should I use ISharedObject for this purpose?
You can. ISharedObjects were specifically designed to provide a unit of encapsulation for replicated state (i.e. generally any state defined within the ISharedObject implementation class. The thing that ISharedObjects give you over IChannels is:
1) A greater degree of control over when and how the replication takes place (e.g. partial replication) 
2) More asynchronous notifications from the container
3) A central place (the ISharedObject) to put event handling/sending logic for a given class of state...that is, it gives some greater encapsulation of the protocol used to update/synchronize the state than do channels. 4) More utlity classes (e.g. BaseSharedObject) and extensible event processing code (event processors), as well as a framework for implementing transactional replication. 
Basically, IChannels are simpler, but provide less flexibility.



When ECF 0.6.0, ECF's Example Application was using GEF and EMF
to share model editor,before I saw.But now I can't find this applicaiton
in the CVS repository. Where is it now?
It's still there. We stopped distributing it as a feature because we needed to reduce the number of features we deploy for Europa, and it had/has a dependency on EMF and SDO, and we were requested to remove unnecessary dependencies where possible.
We frankly haven't kept up on the maintenance and testing of this app, as well, because of resource limitations. So although all the code has been updated, it hasn't been tested in a while. 

Here is the project set file for the two additional 'gef editor' projects:

<?xml version="1.0" encoding="UTF-8"?>
<psf version="2.0">
<provider id="org.eclipse.team.cvs.core.cvsnature">
<project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ecf/plugins/org.eclipse.ecf.example.sdo.gefeditor,org.eclipse.ecf.example.sdo.gefeditor"/> <project reference="1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse.ecf/plugins/org.eclipse.ecf.sdo,org.eclipse.ecf.sdo"/> 
</provider>
</psf>

Note that these need EMF+SDO installed to compile.
If there is sufficient desire/demand we can build this feature occasionally. We can't really add it to the Europa build because of the EMF+SDO dependency, but we could build it by hand if people want it. 

Scott



Thank you for reading this mail.
Regards

KONDO,Hiroki

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

Back to the top