Marc Lehmann wrote: > On Wed, Feb 06, 2002 at 02:11:28PM +0100, Dave Neary <[EMAIL PROTECTED]> 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:
This is untrue (or at least, true only by convention). There's a solid argument that all metadata is plug-in independant, and therefore belongs in the gimp- group. But there's nothing that forces people to honour any parasite naming 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 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. That's the major part of the problem. If someone adds metadata that's not documented, that's a problem. It's a problem because there's no one place that someone can go and say that they have the definitivelist of parasites. That's fine if there are only a few, but if there are many, tracking them becomes a chore. And more it leads to the possibility of inconsistency. > > 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. Yes, it does. We would have one parasite, named something original like 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 forgot 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 (and anyone who thinks it doesn't is living in a dreaml world) it becomes at 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 we > > 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 he's 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 problem > to solve. Adding yet another layer makes the situation worse, not better > ;) (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 terrible 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. Cheers, Dave. _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
