Re: Updated metadata proposal

[Christopher Curtis <ccurtis ee fit edu>]

On 26 Aug 1998, Tom Tromey wrote:

> I've updated the document.  I forgot to delete a paragraph in my
> previous revision.  The `file' command (or analogue) will indeed be
> used in some situations.
> 
> Christopher> #2: You have two different APIs to get "metadata".  A
> Christopher> non-fast (the default) and a 'fast' method.  I would
> Christopher> suggest
> 
> 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.

I'm sorry, but I find this very confusing.  I would think that by 'fast',
you mean a regex or extension type system (*.gif, eg) whereas a non-fast
lookup would involve using the 'file' command.

If this is the case, *I* would use the regex by default, and the 'file' as
a more certain level.  Implementation is of course up to you, but this
seems like it would incur significant overhead.  To me, 'file' lookups
would rarely be required.

> Christopher>   b) changing the 'get' API from:
> Christopher>        get(file,name,size,buffer)
> Christopher>      to
> Christopher>        get(file,name,size,buffer,confidence_level)
> Christopher>      where confidence_level is the (user-supplied?) default.
> 
> I don't understand.  Confidence in what?

Using the above system, there could be syslog-style levels, ie:
CONF_ABSOLUTE: use 'file'+file format info
CONF_CERTAIN:  use 'file'
CONF_RELATIVE: use regex/extension

Something of that nature.  If the programmer simply passed NULL as a
confidence level, the system-(user-)supplied default would apply.

> We could support various user options to control the implementation,
> for instance making "fast" the default.  But that should be internal
> to the implementation, not part of the API.  I'm in favor of heavy
> user customizability.

As am I.  But I also prefer more inclusive APIs, I guess.  that is, rather
than specify a new API for each possible file type lookup method, make the
method a parameter (with a default) in the API.  In my example, this is
the 'confidence_level'.  Perhaps the name is misleading.

It's simply there to recognize tar files as *.tar, or to recognize
file.tar as a JPEG if someone renamed it silly like that.  <shrug>

> Christopher> Also, your document is a little unclear here.  It
> Christopher> specifies an (int *) and a (char **), indicating that a
> Christopher> 'get' would return (??), and describing that this would
> Christopher> retrieve a single piece of data.
> 
> 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).  The functions that return the data associated with some
> key actually return two values: the size of the data, and the bytes.
> These are returned in `result' parameters.

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

Are there provisions to open a file using several methods or not?  That is
to say ...

> Christopher> I would hope that a 'get' would be able to return an
> Christopher> array of data - is this not the case?
> Christopher> ie:   get("file.jpg","view",size_array,view_array,NULL)
> Christopher>     would return { 3, 3, 5 }, { "ee", "xv", "gimp" };

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

> The sketch of the initial implementation is checked in, so you can
> look at it if you want.  It doesn't even compile yet, but I believe
> enough information is there so you can tell where I'm headed.  Perhaps
> the code explains it better than my document.

Okay.

Christopher