Re: metadata
- From: Christopher Curtis <ccurtis ee fit edu>
- To: Tom Tromey <tromey cygnus com>
- cc: Miguel de Icaza <miguel nuclecu unam mx>, gnome-list gnome org
- Subject: Re: metadata
- Date: Thu, 17 Sep 1998 22:31:00 -0400 (EDT)
On 17 Sep 1998, Tom Tromey wrote:
> Christopher> The only problem I see with that is that each program
> Christopher> that wants to access this data must then be written to
> Christopher> understand data lists. This seems like a needless
> Christopher> complication for the client.
>
> The metadata code in gnome-libs is simply a mechanism for associating
> bits of data with files. The library makes no attempt to understand
> this data; it is manipulated opaquely.
>
> Two clients are always going to have to agree on the interpretation of
> a piece of metadata.
This is okay, but seems suboptimal, imo. However, I suppose that it can
be modified later, just like Microsoft has always done with such things as
CreateWindow() and CreateWindowEx().
However, I think that there are going to be needs where this is going to
be a limitation. MC (I presume that's the file browser) is a user-level
example, but might another program want to open a file? Like Netscape's
plugins? In this specific case, there is no way to assign multiple
actions to Open.
This may not be as big of a limitation as I percieve. But then, somebody
who's never seen a door probably sees nothing wrong with climbing out the
window all the time.
> Christopher> Sure. But there was something in what was said that made
> Christopher> me question if a method could be overriden. Taking the
> Christopher> exact same example as above, would Action.Print for *.a
> Christopher> override Action.Print for *, or would it compliment it?
> Christopher> That is, do I now have two ways to Action.Print *.a
> Christopher> files, or do I only have the most specific case?
>
> It depends on how the application structures its key/value use.
So the program has to assemble, organize, and figure out what to do with
each piece of metadata itself? I had hoped that it would be a bit more
transparent to the end application...
> If the key associated with a file is "Action.Print", then there will
> only be one possible value -- the most specific one.
>
> I think that always choosing the most specific value is the correct
> thing to do. In my view, using multiple values is a value structuring
> decision.
Really?
I'm having a hard time coming up with examples, but this seems wrong.
What about something like:
Class Image
{ *.gif
*.jpg
*.png
*.bmp
*.xpm
}
{Image}.Action.View: xv
{*.gif}.Action.View: ShowGifAttr
Surely you wouldn't want to disable the default view method.
Or do you intend to simply say that all applications must avoid name
collision?
Well, ... here's an example I've used from OS/2: I have a bunch of files
associated with a program. I then downloaded a new program that happens
to operate on those same files. Under OS/2, when this new program
associated files it could deal with with itself, it added itself to a list
of methods for a property of the object. Under your scheme, it would
replace the association. Then you end up with *.htm associated with
Microsoft Internet Explorer and *.html associated with Netscape (for
instance). Or you install 'e' thinking you'll have a look at it and all
of a sudden it's changed all your associations and isn't as nice as xv, or
doesn't recognize your thumbnails, or whatever, and you want it back. But
there's no easy way, unless each client has some sort of 'reassociate'
button that you have to push, or you have to reinstall the app, or go into
the registry editor ... or any other number of horrible things.
Despite what you may or may not think of OS/2, it has an excellent object
model. Not only are data files associated with programs, but programs are
associated with data files (these are different things). ...Uhm, yeah.
So there ya go ... use OS/2 or something.
But I really find the single-key, single-data schema very poor. I like
Object->Property->Method_S_ and would miss it if it were not integral to
how Gnome views metadata.
Why would you want to make two authors agree how to store multiple sets of
data with a single key, having them duplicate their code, when it should
be an intrinsic part of the library?
Christopher
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]