Re: metadata

[Tom Tromey <tromey cygnus com>]

>> The data attached to a key is arbitrary.  You could store a list of
>> stuff there if you want.

Christopher> The only problem I see with that is that each program
Christopher> that wants to access this data must then be written to
Christopher> understand data lists.  This seems like a needless
Christopher> complication for the client.

Ok.  I think we are miscommunicating at a more fundamental level.

The metadata code in gnome-libs is simply a mechanism for associating
bits of data with files.  The library makes no attempt to understand
this data; it is manipulated opaquely.

Two clients are always going to have to agree on the interpretation of
a piece of metadata.


Christopher> If a client wants to figure out how to open the file, it
Christopher> would request "Gnome.Open" and (well, I guess this could
Christopher> replace .Open.0) whatever key this requested would be
Christopher> returned.  In the case above, the key value stored in
Christopher> Gnome.Open.2 would be returned.  This way you can change
Christopher> default associations without breaking other associations.
Christopher> In addition, then you would also need (aside from
Christopher> get_key()) a get_key_list() to return all keys,
Christopher> preferrably as char *[] array.

This all sounds like policy-level stuff associated with some
particular application of the metadata layer.  It could easily be
handled by writing a small wrapper for the pieces that matter.

I don't think it is appropriate for all uses of metadata.

It might be appropriate for this application in MC.  On that, I'm
agnostic.

Christopher> Sure.  But there was something in what was said that made
Christopher> me question if a method could be overriden.  Taking the
Christopher> exact same example as above, would Action.Print for *.a
Christopher> override Action.Print for *, or would it compliment it?
Christopher> That is, do I now have two ways to Action.Print *.a
Christopher> files, or do I only have the most specific case?

It depends on how the application structures its key/value use.

If the key associated with a file is "Action.Print", then there will
only be one possible value -- the most specific one.

I think that always choosing the most specific value is the correct
thing to do.  In my view, using multiple values is a value structuring
decision.

Tom