Re: [ecf-dev] Two issues I feel that needs a healthydiscussion overbefor

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Remy,

Remy Suen wrote:
> Hi Scott,
>
> > If we end up going with splitting the ECF core plugin I would suggest we
> > consider 3 resulting plugins
> >
> > identity (namespace extension point):  org.eclipse.ecf.core.identity
> > container (containerFactory extension point):
> > org.eclipse.ecf.core.container
> > shared object (sharedObjectFactory extension point):
> > org.eclipse.ecf.core.sharedobject
>
> What exactly is going to be identity? The IContainer interface defines
> methods that requires Namespaces and IDs, so how do you plan to split
> those two apart?

The 'container' bundle would have to depend upon the identity bundle.  
I'm thinking that the identity bundle could contain just 
org.eclipse.ecf.core.identity.*

> > But before we go too much further in these directions...do people really
> > feel this is necessary?  That is, do the size reduction benefits (<
> > 136K) obviously outweigh the overhead (addl complexity, more meta files,
> > etc) of having multiple plugins?  Perhaps the answer is obviously 'yes',
> > but I just want to explore this a little before we just do it.
>
> Tough call, sorting by size within the plugins/ folder do show quite a
> few plug-ins that are below the 100kb mark. Perhaps Pascal or Philippe
> can comment on this bit. Though I think that the question we need to
> ask ourselves right now is "how often do bundles/plug-ins that depensd
> on org.eclipse.ecf at the moment actually use the shared object subset
> of interfaces/classes?" Going through org.eclipse.ecf.presence, I
> notice that pretty much nothing is used besides ID and IContainer, and
> we know org.eclipse.ecf.filetransfer is similar per previously
> discussed. I'm not really familiar with the other plug-ins, so I can't
> comment on those.

In practice, the main use of the shared object/sharedobjectcontainer 
code is to support provider implementations.  Shared objects give some 
notion of 'reusable' components for ECF containers.

For example, one way to implement an API like remoteservice API 
(org.eclipse.ecf.remoteservices) is to build a shared object that 
implements IRemoteServiceContainer, and then reuse that shared object on 
*all* providers that support ISharedObjectContainer.    I've recently 
doing this via the platform org.eclipse.core.runtime.adapters extension 
point (e.g. see org.eclipse.ecf.providers.remoteservice/plugin.xml).  
This allows reuse of the code implementing IRemoteServiceContainer on 
multiple providers that implement ISharedObjectContainer (like the ECF 
generic, xmpp, jxta, and jms).

This doesn't by any means mean that the shared object packages/code 
currently in core *must* stay in core (and all this would  continue to 
work with a sharedobject plugin outside of core).  But it does serve 
some function as obviously providers must be written and this does give 
some useful support for creating providers in a component-based fashion.

Anyway...I'm open to splitting things out...and maybe that is the right 
thing.  I did get Pascal's comments and I know it's a good idea to make 
as small as possible for small runtime support (which absolutely I want 
to be there).

Thanks,

Scott


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