[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] OBR2

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)

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...

- 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.

- 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)