[equinox-dev] OBR2

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

I checked out the discussion at http://mail-archive.objectweb.org/oscar/2005-05/msg00039.html
and have two main comments
1) the markup is very verbose and will
result in large metadata files being downloaded as the repo grows

2) the use of LDAP filters is cool but
has the problem that you can then never reason about the requirements of
a bundle.  All you can ever do is run the filter and see if passes.
 This is general but it is then hard to explain to potential users/consumers
what they can do with the bundle and what its requirements are.  You
can't show someone an LDAP filter and expect them to understand what they
need.  Also, what happens when attributes are multivalued like the
Required-ExecutionEnvironment.  This is actually one of the ones that
is causing pain right now.

An approach that I was thinking of was
to simply include the manifest in the metadata.  This is a syntax
that is already defined and is familiar to bundle developers.  I have
been laboring over a table of eclipse plugins that currently has 7 columns
of attributes associated with each plugin.  See (this will move in
the near future)
        http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/plugins.html

It seems that every time I look at the
table, another column gets added because there is some new characteristic
(capability) that comes up.  Then I have to go over all 100 bundles
and figure out values.  Then someone changes something and I have
to go and edit the table.  It would be much better to have people
markup their bundles and then have a tool that extracts the info and reasons
about it.  Similarly, someone looking for a bundle will want to be
able to search on these characteristics.  The characteristics can
also be aggregated as bundles are grouped...

Cons
- it clutters the manifest
- you still have the problem of how
to express the dependencies (eg., the LDAP filter)
- There may well still be things that
are not well captured.

Pros
- It puts all the info in one place
- if you find a bundle in the street
you can understand it 
- the headers are candidates for inclusion
in future specs assuming they are interesting/popular (e.g., Required-ExecutionEnvironment)

Jeff