On Sun, Apr 4, 2010 at 6:01 PM, Scott Lewis <slewis@xxxxxxxxxxxxx>
My only comment about discovery is that ECF also has a discovery API (org.eclipse.ecf.discovery) ...
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.
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.