Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » Use of BaseSharedObject
Use of BaseSharedObject [message #589555] Mon, 24 October 2005 11:55 Go to next message
Didier Villevalois is currently offline Didier Villevalois
Messages: 86
Registered: July 2009
Member
Hi again,

It seems to me that
org.eclipse.ecf.provider.generic.sobject.BaseSharedObject provides a
base implementation of ISharedObject. I would tend to use it as the
basis for the implementation of my shared objects.

However its location (in the org.eclipse.ecf.provider.generic plugin)
tells me it is not for public use.

But no package at all in this plugin refers to that code. Should this be
located in the main ecf plugin ? And so may i use it ?

Thanks. Didier.
Re: Use of BaseSharedObject [message #589574 is a reply to message #589555] Mon, 24 October 2005 15:37 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 966
Registered: July 2009
Senior Member
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


Ptitjes wrote:
> Hi again,
>
> It seems to me that
> org.eclipse.ecf.provider.generic.sobject.BaseSharedObject provides a
> base implementation of ISharedObject. I would tend to use it as the
> basis for the implementation of my shared objects.
>
> However its location (in the org.eclipse.ecf.provider.generic plugin)
> tells me it is not for public use.
>
> But no package at all in this plugin refers to that code. Should this be
> located in the main ecf plugin ? And so may i use it ?
>
> Thanks. Didier.
Re: Use of BaseSharedObject [message #589596 is a reply to message #589574] Thu, 27 October 2005 09:08 Go to previous messageGo to next message
Didier Villevalois is currently offline 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 #589607 is a reply to message #589596] Thu, 27 October 2005 09:23 Go to previous messageGo to next message
Didier Villevalois is currently offline Didier Villevalois
Messages: 86
Registered: July 2009
Member
Hi again,

An addition:

In the eventuality of such changes i described in my last post, the new
usage would be the following:

If i need shared object replication, i extends BaseSharedObject and in i
instanciate in my constructor a SharedObjectReplication passing it the
good informations about eclusions/inclusions (by a filter), time out...

If i don't need shared object replication, i extends BaseSharedObject,
and i instanciate some other SharedObjectServices.

Thus the constructor of BaseSharedObject do not take anymore the shared
object replication informations and the adapter method is hand coded.

Didier.
Re: Use of BaseSharedObject [message #589613 is a reply to message #589596] Thu, 27 October 2005 21:35 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 966
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
Re: Use of BaseSharedObject [message #589625 is a reply to message #589607] Thu, 27 October 2005 21:37 Go to previous message
Scott Lewis is currently offline Scott Lewis
Messages: 966
Registered: July 2009
Senior Member
Hi Didier,

Ptitjes wrote:
> Hi again,
>
> An addition:
>
> In the eventuality of such changes i described in my last post, the new
> usage would be the following:
>
> If i need shared object replication, i extends BaseSharedObject and in i
> instanciate in my constructor a SharedObjectReplication passing it the
> good informations about eclusions/inclusions (by a filter), time out...
>
> If i don't need shared object replication, i extends BaseSharedObject,
> and i instanciate some other SharedObjectServices.
>
> Thus the constructor of BaseSharedObject do not take anymore the shared
> object replication informations and the adapter method is hand coded.

Seems reasonable. Let me think about the design of this a little more.

Thanks again for the comments and suggestions. We will definately take
them into acccount. The existing API is what I would consider
'pre-pre-provisional' so expect lots of changes.

Scott
Previous Topic:Sun Enterprise Server
Next Topic:calendaring and scheduling
Goto Forum:
  


Current Time: Tue Jul 29 02:42:06 EDT 2014

Powered by FUDForum. Page generated in 0.02374 seconds