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.
Yes.
> 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
inconsistency.
> 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
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
