Re: Updated metadata proposal



Christopher> a) making 'fast' the default

>> I disagree.  In general `fast' lookups should only be made when the
>> programmer knows this is required.  It rarely is.  So the default
>> should be to do the right thing.

Christopher> I'm sorry, but I find this very confusing.

No problem; I'll try to explain.

Christopher> I would think that by 'fast', you mean a regex or
Christopher> extension type system (*.gif, eg) whereas a non-fast
Christopher> lookup would involve using the 'file' command.

I thought I had addressed this in the document.  Anyway, the idea is
that lookups are done in a series of phases.  A fast lookup simply
leaves off the final phase, which involves the use of the `file'
command.

The `file' command is actually only used to try to determine the
file's type; the actual metadata in this case is associated with the
type.  David Jeske's had an idea to let a metadata lookup be
associated with a given command which could be run to extract the
information.  This is a generalization of using `file'.  I like the
idea, but I don't plan to implement it.  (It could be added later with
only compatible extensions to the API.)

Christopher> Implementation is of course up to you, but this seems
Christopher> like it would incur significant overhead.  To me, 'file'
Christopher> lookups would rarely be required.

Since they always follow the other lookups, if they are actually
rarely required then `file' will rarely be run.

>> Sorry.  A piece of metadata is just a chunk of raw data.  The
>> metadata code doesn't interpret it in any way (except in one
>> special case, the `type' key).

Christopher> This seems limited, but if that's what you want to do ...

Limited in what way?  You can store arbitrary data.

Christopher> Are there provisions to open a file using several methods
Christopher> or not?

Christopher> Can a single file be associated with all three above
Christopher> programs using the same method (eg, "open")?

Interpretation of the metadata is up to the user (except for the
"type" metadata -- the implementation itself is a user of this).  So
in this case it depends on what "everybody" agrees the interpretation
of `open' will be.

Of course, as I say in my document, whether metadata is used for this
is actually an implementation decision of a different layer.  I think
file opening and the like should be handled via CORBA.

Tom



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]