felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Gogo inspect command
Date Wed, 17 Aug 2011 15:25:12 GMT
Following up on this, I've started to implement the new "inspect" 
command. I realized that since we now have a generic model, that it 
would make more sense to reverse the parameters. For example, in the old 
"inspect" command you would do something like:

     inspect package capability

Which would list all exported packages. However, with the new generic 
model I think it makes more sense to reverse the order:

     inspect capability osgi.wiring.package

 From this example, there isn't much difference, but it makes it more 
natural to support stuff like:

     inspect capability *

To list all capabilities, or:

     inspect capability osgi.wiring.*

To list all OSGi capabilities.

My rationale is that the "type" of entity being queried (i.e., 
capability or requirement) is more general so it should be specified 
first, then the specific namespace is used to create a more fine-grained 
list of entities. Seem reasonable?

Another thing, since people running on older frameworks won't be able to 
query the generic model, we need to keep around the old "inspect" 
command too, so that it will continue to work no matter which platform 
you are on. If you are on an R4.3 framework you'll get the new command, 
if not you'll get the old one.

Given that, should we modify the old inspect command to be more similar 
to this (at a minimum reverse its parameters too) or should we keep it 
the same?

-> richard

On 8/15/11 11:10, Richard S. Hall wrote:
> When I created the "inspect" command for Gogo, I just made up the 
> terminology, which gave us things like:
>     inspect package capability
> Which could also be abbreviated:
>     inspect p c
> Or other abbreviations since I was using startsWith() to compare the 
> arguments.
> The first argument to the inspect command, I called "type" although 
> more technically it is the "namespace" of the capability/requirement. 
> The following types are supported:
>     package (Import-Package)
>     bundle (Require-Bundle)
>     fragment (Fragment-Host)
>     service (generic service dependency)
> Now, for OSGi R4.3, the OSGi spec has adopted a more generic 
> dependency model (similar to the model that the Felix framework uses 
> internally). As a result, most of the above types (now explicitly 
> called namespaces) have new official values:
>     osgi.wiring.package
>     osgi.wiring.bundle
>     osgi.wiring.host
> Note that there is no official OSGi namespace for services yet and the 
> fragment namespace is actually the reverse of what I was using. 
> Further, new Provide-Capability/Require-Capability headers give you 
> the ability to have arbitrary dependencies for custom namespaces.
> To deal with this, I'd like to change the "inspect" command like this:
>  1. Drop old namespace names (i.e., package, bundle, fragment).
>  2. Adopt new official namespace names (i.e., osgi.wiring.package,
>     osgi.wiring.bundle, osgi.wiring.host).
>  3. Allow abbreviations to be entered using the first letter of each
>     namespace (e.g., owp == osgi.wiring.package); this would also
>     provide a generic way to handle abbreviations for custom
>     namespaces too...of course, you will also be able to type in the
>     entire namespace name too.
> The "service" namespace would stay the same at least until there is an 
> official namespace for it.
> Thoughts?
> -> richard

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message