|
|
| Re: Use of BaseSharedObject [message #589596 is a reply to message #589574] |
Thu, 27 October 2005 13:08   |
 Didier Villevalois
Messages: 86
Registered: July 2009 |
Member |
|
|
Hi Scott,
So i will use BaseSharedObject for the shared objects at the root of my
system. Let me expand a bit on them, so that i can comment on classes in
the ".sobject" package. Those objects are "System", "Node", and
"Workspace".
My "System" object won't use the SharedObjectReplication support class.
It will instead work more like the Chat object you spoke about in an
earlier post. I mean that every client will instanciate their own System
object, all with the same id. I will try to make a support class (like
SharedObjectReplication) to handle most of the work (which is obviously
is quite none).
My "Node" object will use the SharedObjectReplication support class. In
fact Node objects represent client containers joining the system. And i
need a representant of each in all containers. In addition, Nodes will
hide inter-container communication from a application point of view by
simply maintaining the container id of the primary instance.
My "Workspace" object will also use the SharedObjectReplication support
class. Workspace objects are aggregation of some Nodes. Nodes assigned
to a workspace are meant to coordinate to provide the application service.
Above a Workspace, a "WorkspaceManagementPolicy" object will use the
SharedData service (feeded via some aspects) to handle the shared data
of the Workspace. But i'll come back on this in another post as i've got
questions about the SharedData service.
So,
1) The getReplicaDescriptions(..) method from ISharedObjectInternal is
very specific to SharedObjectReplication. In the eventuality that other
support classes like SharedObjectReplication (sorts of tiny ecf
services) could be made why not move that method in another place. I
would tend to put it in SharedObjectReplication as a protected method
(so that it can be anonymously overiden). The base implementation would
be as simple as the current one except that the shared object
configuration has to be known from SharedObjectReplication (either we
pass it in its constructor, or we expose it via SharedObjectInternal
which is maybe less safe but not sure).
2) You take in the SharedObjectReplication constructor a id array of
excluded containers from the replication. I find this very limitative.
This could also be a included containers id array. In my case, as i know
containers i'dd like to replicate to, i've got extra work to compute the
excluded container ids from the group member ids and then
TCPCommitEventPocessor computes the replication included container ids
by reprocessing the group member ids. Wouldn't it be possible to
abstract the filter method somewhere ? Maybe this could also be
implemented in SharedObjectReplication (as a protected method so that it
can be overiden).
3) Shouldn't TCPCommitEventProcessor be private to SharedObjectReplication ?
Thanks for your help,
Didier.
Scott Lewis wrote:
> Hi Didier,
>
> The org.eclipse.ecf.provider.generic.sobject.BaseSharedObject has been
> in development and not undergone a lot of testing...which is why it's
> currently there instead of the core API. Our intention was to
> eventually move it to the org.eclipse.ecf API so that you could do
> exactly as described.
>
> I feel it needs a little more testing before going into the core
> API...and perhaps you could help us with that and we could move it into
> the core relatively soon.
>
> I would suggest that you use it in org.eclipse.ecf.provider, provide us
> with some testing and we'll plan on moving it into the core relatively
> soon. If that works for you we would be very appreciate of some testing
> and bug feedback.
>
> Thanks,
>
> Scott
|
|
|
|
| Re: Use of BaseSharedObject [message #589613 is a reply to message #589596] |
Fri, 28 October 2005 01:35 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Didier,
Ptitjes wrote:
> Hi Scott,
>
> So i will use BaseSharedObject for the shared objects at the root of my
> system. Let me expand a bit on them, so that i can comment on classes in
> the ".sobject" package. Those objects are "System", "Node", and
> "Workspace".
>
> My "System" object won't use the SharedObjectReplication support class.
> It will instead work more like the Chat object you spoke about in an
> earlier post. I mean that every client will instanciate their own System
> object, all with the same id. I will try to make a support class (like
> SharedObjectReplication) to handle most of the work (which is obviously
> is quite none).
>
> My "Node" object will use the SharedObjectReplication support class. In
> fact Node objects represent client containers joining the system. And i
> need a representant of each in all containers. In addition, Nodes will
> hide inter-container communication from a application point of view by
> simply maintaining the container id of the primary instance.
>
> My "Workspace" object will also use the SharedObjectReplication support
> class. Workspace objects are aggregation of some Nodes. Nodes assigned
> to a workspace are meant to coordinate to provide the application service.
>
> Above a Workspace, a "WorkspaceManagementPolicy" object will use the
> SharedData service (feeded via some aspects) to handle the shared data
> of the Workspace. But i'll come back on this in another post as i've got
> questions about the SharedData service.
>
> So,
> 1) The getReplicaDescriptions(..) method from ISharedObjectInternal is
> very specific to SharedObjectReplication. In the eventuality that other
> support classes like SharedObjectReplication (sorts of tiny ecf
> services) could be made why not move that method in another place. I
> would tend to put it in SharedObjectReplication as a protected method
> (so that it can be anonymously overiden). The base implementation would
> be as simple as the current one except that the shared object
> configuration has to be known from SharedObjectReplication (either we
> pass it in its constructor, or we expose it via SharedObjectInternal
> which is maybe less safe but not sure).
The reason it's not protected and on the ShareObjectReplication is that
the other methods on SharedObjectInternal have to be available to the
TPCommitEventProcessor class (in addition to getReplicaDescriptions(...).
I'm going to rethink this class and interface organization a little bit,
however...and I appreciate your comments.
>
> 2) You take in the SharedObjectReplication constructor a id array of
> excluded containers from the replication. I find this very limitative.
> This could also be a included containers id array. In my case, as i know
> containers i'dd like to replicate to, i've got extra work to compute the
> excluded container ids from the group member ids and then
> TCPCommitEventPocessor computes the replication included container ids
> by reprocessing the group member ids. Wouldn't it be possible to
> abstract the filter method somewhere ? Maybe this could also be
> implemented in SharedObjectReplication (as a protected method so that it
> can be overiden).
It might be a good idea to introduce a filter interface that gets called
back to make the include/not include decision rather than a
collection/ID[]. I think I'll include this in the restructuring
mentioned above.
>
> 3) Shouldn't TCPCommitEventProcessor be private to
> SharedObjectReplication ?
Yes, thanks. I've updated the code and checked it in.
I'm anticipating doing two things for this code (in sobject package):
1) Refactor it (taking into account suggestions above, and making some
other changes for clarity, etc).
2) Move everything in this package into the ECF code plugin
(org.eclipse.ecf). I've been anticipating doing both of these things,
but simply not had the time to complete to this point...but I hope to
get these changes into 0.5.0 release within the next week.
Thanks for your comments...very helpful.
Scott
|
|
|
|
Powered by
FUDForum. Page generated in 0.03252 seconds
] 
Search
Help
Register
Login
Home
