3 Dec
2002
3 Dec
'02
10:30 p.m.
On Tue, Dec 03, 2002 at 01:58:29PM -0800, Tim Hockin wrote:
I have to say I agree with Tim here -- internal, inseparable strings are
much simpler for both the host and plugin authors to deal with, and don't
force apps to link against random external libraries (xml or rdf or
whatever) just to get at a few necessary strings. The core stuff (name,
description etc.) is not actually "meta" at all, they're fields which just
happen to be of string type.
If a host needs to parse xml, or even hit the network, just to access
core information, that significantly raises the barrier to entry for
developing compatible software. The barrier to entry is already
high enough (the ability to write or load dynamic libraries and design
a callback based plugin) -- high enough that I've seen a few people shy
away from it already. Adding to this will only slow the uptake, or put
us in a situation where all our half-developed apps can only do half of
what's required of the standard, which will be awful.
For stuff that is actually metadata (keywords, location of publication etc.)
... if you want to reference external metadata by unique id, I propose that
the data type of the unique id be a URL :)
Conrad.
From: Steve
Harris <S.W.Harris(a)ecs.soton.ac.uk>
If you're going to support metadata, support
the Dublin Core, but generally
extrnal metadata is better than internal. Just provide a unique ID and
metadata can refer to that.
Firstly, I hate the idea that a plugin writer needs to procure a unique ID.
Secondly, I think some meta-data needs to be IN the plugin. Now, maybe
'notes', and 'url' can be outside the plugin, but
author/copyright/license/version can't. Think of commercial plugin (I know,
pipe dreams, but just pretend :). As a commercial vendor you DO NOT want it
to be trivial for a person to 'lose' the info about the license. I can
think of a several reasons to keep it all together, and no good reason NOT
to. Specifically, this data is inseperable from the plugin. As an author,
I want this data joined at the hip with the plugin. Further, the idea that
a plugin consists of a single .so file appeals to me.