[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
JM> I checked out the discussion at
JM> http://mail-archive.objectweb.org/oscar/2005-05/msg00039.html and
JM> have two main comments
JM> 1) the markup is very verbose and will result in large
JM> metadata files being downloaded as the repo grows
Well, that is a problem for XML ... fortunately it does compress
rather well.
JM> 2) the use of LDAP filters is cool but has the problem that
JM> you can then never reason about the requirements of a bundle. All
JM> you can ever do is run the filter and see if passes. This is
JM> general but it is then hard to explain to potential
JM> users/consumers what they can do with the bundle and what its
JM> requirements are. You can't show someone an LDAP filter and
JM> expect them to understand what they need. Also, what happens when
JM> attributes are multivalued like the Required-ExecutionEnvironment.
JM> This is actually one of the ones that is causing pain right now.
Well, the LDAP filter very nicely support the multi valued attributes,
and much more. It also scales very well to SQL and other databases.
First I think we need a generic approach. Once we go to semantic
tags (e.g. have an XML tag for Require-Bundle) then we immediately
have a spec versioning problem and the software tends to become more
complicated. The generic model allows the repos to be quite flexible.
A simple version of this model (JSR 124) uses requirements and capability
properties. That makes it easier to "reason" about but is imho not
very flexible (I worked with it once).
For each capability, you can define what requirements match. This is
cacheable information. So you may not know exactly why a requirement
matches, but you know what requirement matches.
I had a discussion with Richard about the naming the requirements. In
his proposal he embeds the type in the filter. I still think I would
prefer named requirement types, where some could have a defined
meaning.
JM> An approach that I was thinking of was to simply include the
JM> manifest in the metadata. This is a syntax that is already
JM> defined and is familiar to bundle developers. I have been
JM> laboring over a table of eclipse plugins that currently has 7
JM> columns of attributes associated with each plugin. See (this will
JM> move in the near future)
JM>
JM> http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/plugins.html
JM> It seems that every time I look at the table, another column
JM> gets added because there is some new characteristic (capability)
JM> that comes up. Then I have to go over all 100 bundles and figure
JM> out values. Then someone changes something and I have to go and
JM> edit the table. It would be much better to have people markup
JM> their bundles and then have a tool that extracts the info and
JM> reasons about it. Similarly, someone looking for a bundle will
JM> want to be able to search on these characteristics. The
JM> characteristics can also be aggregated as bundles are grouped...
It absolutely MUST be possible to generate the metadata from the
manifest.
It seems that your table requires a lot of flexibility, which I think
is provided by the generic capability/require model of OBR2?
Kind regards,
Peter Kriens
JM> Cons
JM> - it clutters the manifest
JM> - you still have the problem of how to express the
JM> dependencies (eg., the LDAP filter)
JM> - There may well still be things that are not well captured.
JM> Pros
JM> - It puts all the info in one place
JM> - if you find a bundle in the street you can understand it
JM> - the headers are candidates for inclusion in future specs
JM> assuming they are interesting/popular (e.g.,
JM> Required-ExecutionEnvironment)
JM> Jeff
--
Peter Kriens Mob +33633746480
9C, Avenue St. Drézéry Tel +33467542167
34160 Beaulieu, France Tel +15123514821
Tel +33870447986
AOL,Yahoo, Skype pkriens ICQ 255570717
