[
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