Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Re: [GSoC] Restlet integration with Equinox 
Hi Rob,

Rob Heittman wrote:

Inline:
On Sun, Apr 4, 2010 at 6:01 PM, Scott Lewis <slewis@xxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxx>> wrote: 

    My only comment about discovery is that ECF also has a discovery
    API (org.eclipse.ecf.discovery) ...
[snip] 
    The OSGi remote services spec defines a thing called a 'config
    type'...which is just a String that uniquely identifies a type of
    remote service provider.  ECF maps this 'config type' to identify
    an ECF IContainer type/factory...and this string identified the
    provider used underneath (e.g. ecf.r-osgi.peer,
    ecf.generic.client, ecf.xmpp.client, etc)...so to use a particular
    provider/protocol to register/publish a remote service all one has
    to do is create a provider with new name, specify it as the config
    type to use when registering a remote service, and that provider
    will be used.
Good. I am not immersed in this model yet, but it sounds like a nice, loosely coupled way to accomplish discovery. I'll have a look at what Zookeeper is doing to get more up to speed.
Just to be clear we/ECF have a pending contribution that allows the use of Zookeeper for discovering any/all types of remote services providers. See this bug for details 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=301854
and this blog about the contribution: http://industrial-tsi-wim.blogspot.com/2010/03/ecf-discovery-how-many-zookeepers-does.html 




    I see.  I agree that the use of OSGi services for dynamicity is a
    very useful thing...and another thing that would make sense to do
    within Restlet...assuming OSGi runtime environment.
Naturally. There has been discussion on the Restlet list of the possibility of creating an OSGi "edition" that is more tightly bound to OSGi and requires that it be used inside an OSGi runtime. I suspect, from other work I've done, that this needn't be an "edition" as other Restlet editions are -- conditionally compiled throughout to work in special Java environments, e.g. GWT, GAE, or Android. IIRC that was the last consensus when it came up on the list, too. I suspect that if the appropriate facilities are exposed, all the OSGi runtime-dependent aspects can be put in their own bundle(s). The devil being in the details of "the appropriate facilities are exposed" ... to me this suggests, within Restlet, more reliance on interfaces and less on concrete classes, implemented with an a priori awareness of what we want higher-level features like ECF discovery and OSGi remote services to be able to do with Restlet. 

Sounds excellent to me.

Scott

Back to the top