Re: Updated metadata proposal



>>>>> "Christopher" == Christopher Curtis <ccurtis@ee.fit.edu> writes:

>> http://www.cygnus.com/~tromey/gnoem/metadata.html
>> Please tell me what you think.  Implementation will begin shortly.

Christopher> #1: You have two APIs - one using the 'file' command, one
Christopher> not, yet later in your document you say that you don't
Christopher> want or don't intend to use the 'file' command, using
Christopher> 'type' instead.  I'm not sure what you mean by this
Christopher> (type), but it seems to be contradictory (file).

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.

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?

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.

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.

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" };

Interpretation of the data is up to the caller.

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.

Tom



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