Raphael wrote: > On Tue, 5 Feb 2002, Dave Neary wrote: > > Your points all have merit. My problem is now, and has always been, > > 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 can > 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 it > > parsed in one place. Then people who want to use bits of the metadata > > would just use the bits they wanted, and ignore the bits they didn't > > I do not understand what we would gain by using an XML format to store > a list of name-value pairs if the GIMP is already providing a > mechanism for doing that: the parasites. This would only add an extra > parsing step that is not necessary. It is better to be able to access > 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 of > > 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 of > 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 the > week, and maybe that could be used as a starting point for a "standard > 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 object > > that wants to use bits of it, or multiple objects which are the > > bits. I think the cleanliness of having everything in one place is > > appealing. > > Well, that depends on your point of view: as I see it, the "one place" > 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 advantage > 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 need > 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. Cheers, Dave.
