Marc Lehmann wrote:
> On Wed, Feb 06, 2002 at 02:11:28PM +0100, Dave Neary
> > Parasite naming is non-standard. Anyone can create a parasite with
> > 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:

This is untrue (or at least, true only by convention). There's a solid
that all metadata is plug-in independant, and therefore belongs in the
group. But there's nothing that forces people to honour any parasite
convention. I could write a plug-in that creates a parasite with a
name not
starting with gimp- and uise it in the core, or with the name gimp-
and use it
only in one plug-in.

> > the aim of having a metadata editor at some stage, 50 or 60 pieces
> > metadata with (possibly) non-standard naming is complicated.
> There is no such thing as "non-standard naming" in this case. exif
> provide a standard name, so you need to make one up. Wether oyu make
> one or 50 doesn't really matter, as long as it's documented.

That's the major part of the problem. If someone adds metadata that's
documented, that's a problem. It's a problem because there's no one
that someone can go and say that they have the definitivelist of
That's fine if there are only a few, but if there are many, tracking
becomes a chore. And more it leads to the possibility of

> > You say that any piece of metadata can easily be accessed by name.
> > problem is going to be:  What name? I think keeping stuff in one
> > 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

Yes, it does. We would have one parasite, named something original
gimp-image-metadata, and in one header file somewhere we would have
the definition of the gimp-image-metadata structure, and the
prototypes of
the parsing functions.If someone added an extra bit of metadata and
to document it in the docs, well it's there in the code in the one
place where
all the fields supported in the metadata are - one place, definitive.

> The parasites provide a namespace for this. Inventing
> yet-another-metadata-in-metadata-abstraction doesn't buy clarity.

Perhaps not, but it buys consistency.

> 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.

That's fine, when the documentation is accurate - if it lags behind
anyone who thinks it doesn't is living in a dreaml world) it becomes
best redundant and at worst misleading.

> parasites were created for metadata. If they don't work well
> enough for that parasites should be improved, rather than becoming a
> legacy layer.

To handle something like what we're talking about, you'd need
something paralleling the PDB - a parasite database. And that seems
to me like overkill.

> > 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
> > have two parasites which do the same thing.
> Your approach suffers exactly the same problem, btw.

No, because the PNG developer has the definitive list of parasitres in
the image metadata definition. If he's adding a new bit of metadata
adding it there. And in that case, the duplication should be obvious.

> 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
> to solve. Adding yet another layer makes the situation worse, not
> ;)

(I left in the wink just in case there was a subtlety there I missed
:) )
If someone could convince me that there were a way to get a list of
all the
parasites in use in the gimp (core and plug-ins) using the current
structure of things, then I'd probably go along. I just have this
vision of having a gimp-image-metadata-author in one plug-in, and
gimp-metadata-author in another, and gimp-image-author in another,
and so on. Possibly not for something as obvious as that, but you get
my point.


Gimp-developer mailing list

Reply via email to