On Wed, Feb 06, 2002 at 02:11:28PM +0100, Dave Neary <bolsh@xxxxxxxx> wrote:
> Parasite naming is non-standard. Anyone can create a parasite with any
> name they want.
Untrue. Names beginning with "gimp-" are well-defined as belonging to the
core. The gimp itself must, at one point, know how to deal with these. The
core also is:
> the aim of having a metadata editor at some stage, 50 or 60 pieces of
> metadata with (possibly) non-standard naming is complicated.
There is no such thing as "non-standard naming" in this case. exif doesn't
provide a standard name, so you need to make one up. Wether oyu make up
one or 50 doesn't really matter, as long as it's documented.
> parasites if we were guaranteed a consistent approach throughout the
> gimp, but parasites don't give that guarantee by definition almost.
Why? What are the problems?
> The obvious way to maintain a consistency wrt the metadata is to
> define it in one place, maintain that list in one place, and have it
> parsed into a usable structure when needed.
I think this is exatcly what parasites provide.
> You say that any piece of metadata can easily be accessed by name. The
> problem is going to be: What name? I think keeping stuff in one place
> offers consistency.
Well, the everything-in-a-big-blob-approach doesn't help naming at all. At
one point you simply have to make up names to access the exif information.
The parasites provide a namespace for this. Inventing
yet-another-metadata-in-metadata-abstraction doesn't buy clarity.
> (with a description) to the list. devel-docs/parasites.txt is
> something approaching that. But that makes maintenance pretty
> difficult, compared to having the code document itself (one metadata
> structure with typed fields, and a couple of parsing routines).
I think it's much easier to just look at the documentation rather than to
run through header files until I can find what I need, hopefully with a
sparse one-line comment, even.
> parasites. Having one metadata structure provides that one place.
But parasites _is_ one metadata structure. I don't see why nesting etadata
structures inside each other is a good thing - to me it only complicates
things. parasites were created for metadata. If they don't work well
enough for that parasites should be improved, rather than becoming a
legacy layer.
> the TIFF plug-in, the PNG developer knows nothing about it - if I as a
> lazy developer didn't add it to the list of supported metadata he
> wouldn't know it existed. And let's say I as the PNG developer want to
> use the same data, but I call it a slightly different name - now we
> have two parasites which do the same thing.
Your approach suffers exactly the same problem, btw.
> Those kind of problems are eliminated by definition if all the
> metadata's defined in one place.
And the most natural place for this is parasites, which exist only to hold
metadata. If their definition isn't clear enough then this is the problem
to solve. Adding yet another layer makes the situation worse, not better
;)
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
