On Thu, Feb 07, 2002 at 04:09:01PM +0100, Dave Neary <[EMAIL PROTECTED]> wrote:
> This is untrue (or at least, true only by convention). There's a solid
> argument

(your mail is horribly mis-formatted and very hard to read, btw)

> that all metadata is plug-in independant, and therefore belongs in the
> gimp-

Why is metadata plug-in independent?

> group. But there's nothing that forces people to honour any parasite
> naming

Yes there is, it's called rules and conventions. The gimp is not about
bondage and discipline.

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

You could. You could also send the gimp process a kill signal at anytime.
That doesn't make it correct, or right to do.

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

Sure, the documentation.

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

Another abstraction layer, of course, doesn't help getting rid of

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

So what does this buy us, apart from anothe rlevel of indiraction, to the
current approach which also does all this?

> > The parasites provide a namespace for this. Inventing
> > yet-another-metadata-in-metadata-abstraction doesn't buy clarity.
> Perhaps not, but it buys consistency.

You repeat this again and again. But people fail to see this.

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

Adding yet another place where this has to be documented does not, in my
eyes, improve the situation.

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

"the definitive list" and "adding new bit of metadata" contradict each
other, at least in my mind.

> 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

use grep ;)

> vision of having a gimp-image-metadata-author in one plug-in, and
> gimp-metadata-author in another, and gimp-image-author in another,

If you mean that this should not happen, I agree. But how would the other
approach help this? One author could add a author field and another an
image-author field to the structure. Again, another level of abstraction
doesn't help at all. Either one avoids these bugs, or not.
> and so on. Possibly not for something as obvious as that, but you get
> my point.

Yes, but instead you should gice points on why another metadata layer
would solve the existing problems. IMnsHO doing the same thing in a
slightly different way only increases the places where problems occur.

      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED]      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
Gimp-developer mailing list

Reply via email to