Raphael wrote:
> On Tue, 5 Feb 2002, Dave Neary wrote:
>  > Your points all have merit. My problem is now, and has always
>  > that a parasite per piece of data would mean adding an extra 50
or 60
>  > parasites which would be relatively persistent. That makes things
>  > pretty complicated, to my mind.
> What's the problem with having 50 or 60 parasites attached to an
> image?  The parasites are very small and they are what the GIMP uses
> to store any kind of metadata about an image.  Each of these parts
> easily be accessed or modified by using its name.

Parasite naming is non-standard. Anyone can create a parasite with any
name they want. In terms of providing a consistent metadata set, with
the aim of having a metadata editor at some stage, 50 or 60 pieces of
metadata with (possibly) non-standard naming is complicated. Add to
that that not all metadata parasites will be registered in the same
place, and that any new plug-in can add new metadata, and we begin to
have a problem. I'd have no problem with using a large number of
parasites if we were guaranteed a consistent approach throughout the
gimp, but parasites don't give that guarantee by definition almost.
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. 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.

>  > Instead we could store the whole
>  > metadata in a nice format (say as xml?) as one parasite, and have
>  > parsed in one place. Then people who want to use bits of the
>  > would just use the bits they wanted, and ignore the bits they
> I do not understand what we would gain by using an XML format to
> a list of name-value pairs if the GIMP is already providing a
> mechanism for doing that: the parasites.  This would only add an
> parsing step that is not necessary.  It is better to be able to
> any part of the data directly by using its name.

The extra parsing step certainly isn't necessary, but I don't see it
being a huge overhead. It'd be done twice in the lifetime of a
plug-in - once to parse the parasite into usable data, once to parse
the data back to a parasite. I don't see why that would present a huge
problem for the gains that I see.

>  > I think one structure, defined in one place, makes the handling
>  > metadata cleaner.
> Maybe I am sounding like a broken record, but there is already a
> structure that is designed for handling metadata: this is the list
> parasites.  This is precisely why the parasites were added to the
> GIMP: storage of metadata, and easy access by name.

Where *is* the list of parasites? There are only (as you point out)
about 10 persistent parasites, and the list isn't maintained anywhere.
One possible approach to the metadata thing (I won't call it a problem
yet) is to maintain a list of all the parasites which are used along
with a description, and any time someone adds a parasite, they add it
(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).

> The only thing that is missing is a standard list of names and types
> for all parasites.

This is a pretty big thing.

> It would be trivial to map the names of the all EXIF fields to
> individual parasites.  I will try to post a list before the end of
> week, and maybe that could be used as a starting point for a
> list of GIMP parasites".  I will also have a look at how much effort
> would be needed in order to have the types checked by the GIMP core.

This is certainly the obvious approach, if we are to use multiple
parasites. The problem (and now it's my turn to sound like a broken
record) is that the list would be independant of the code, and thus
there's never going to be one definitive reference for metadata
parasites. Having one metadata structure provides that one place.

>  > And herein lies the crux - one object which is parsed by any
>  > that wants to use bits of it, or multiple objects which are the
>  > bits. I think the cleanliness of having everything in one place
>  > appealing.
> Well, that depends on your point of view: as I see it, the "one
> is the list of parasites.  Several plug-ins are already using this
> "one place" and the access functions provided by the PDB to get or
> change some elements from this list.  I still do not see any
> in using only one element from this list to store another list (or
> another type of data structure, although I do not expect that we
> anything more complex than a list to be used by more than one
> plug-in).

I don't see the parasite handler as one place. As a scenario - say
that the TIFF plug-in wants to set some metadata information (but not
all of it) for a certain image, and later we are saving as PNG, and we
want to set some more metadata with the image, wouldn't you consider
the two plug-ins as two places? If I add a parasite to the metadata in
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. Those kind of problems are
eliminated by definition if all the metadata's defined in one place.


Gimp-developer mailing list

Reply via email to