[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ecf-dev] More interfaces on remote OSGI services page
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Mon, 10 Jul 2006 14:46:05 -0700
- Delivered-to: email@example.com
- User-agent: Thunderbird 126.96.36.199 (Windows/20060516)
Hi Bob, Ken, and all,
This afternoon I put some more of the ideas for OSGI remote service API
that I've been playing around with here:
Note as usual for ECF :-) this says exactly nothing about how these APIs
would be implemented...e.g. they could be implemented with some existing
RPC mechanism, or via RPC built on asych messaging (e.g. ecf generic).
Clearly I think of missing functionality as a feature :). Also, as
discussed during the conf call today the actual implementation bundles
(e.g. whether they are dynamically loaded/installed or rather must be
there to begin with) is left unspecified...meaning that (for example) a
call to getRemoteServiceReferences could actually retrieve the bundles
holding the proxies associated with the given remote service. I think
that's a pretty exciting idea, actually.
Also note that the intention here was to present to remote clients an
OSGI service interface that 'looks' a fair amount like the OSGI 'local'
service interface (e.g. BundleContext.registerService,
BundleContext.getServiceReferences, BundleContext.getService, etc).
This may/may not be a good idea...as Ken hinted at during the
call...that is, it's not clear whether a remote service interface is
best...or some way to access remote bundle code, or certain packages,
within bundle, etc. The process-local OSGI service concept, though, is
at least one that is standardized by OSGI itself...and used in Eclipse
and other RCP apps.
Any thoughts/comments/criticisms/'you are crazy's appreciated.