RE: metadata

["Dries, Joseph" <joseph dries lmco com>]

> -----Original Message-----
> From:	Christopher Curtis [SMTP:ccurtis@ee.fit.edu]
> Sent:	Wednesday, September 16, 1998 11:20 PM
> To:	Tom Tromey
> Subject:	Re: metadata
> 
> On 15 Sep 1998, Tom Tromey wrote:
> 
> > Christopher> Having a 1:1 correlation between a data key and its data
> > Christopher> seems very limiting to me, which the enumerations I hope
> > Christopher> addresses.
> > 
> > I don't understand this comment.
> > 
> > The data attached to a key is arbitrary.  You could store a list of
> > stuff there if you want.
> 
> The only problem I see with that is that each program that wants to access
> this data must then be written to understand data lists.  This seems like
> a needless complication for the client.  It makes more sense to me to have
> data lists be inherant, with a default action.  Perhaps my understanding
> of what you are doing is limited and this is already addressed, but I
> don't think it is.  Example below...
> 
	I believe that Christopher is correct here. It certainly provides a
clear path from storage, implementation, and representation. I know exactly
what I need to edit. The metadata handling library's representation of the
key/value pairs almost directly map to object-menus.

> > >> "Gnome.Open"                Command used to open this file
> > 
> > Christopher> Especially in cases like this.  I would want (for example):
> > 
> > Christopher> Gnome.Open.0 -> Gnome.Open.3
> > Christopher> Gnome.Open.1 -> "emacs $this"
> > Christopher> Gnome.Open.2 -> "php -cgi < $this > $1"
> > Christopher> Gnome.Open.3 -> "netscape $this"
> > 
> > I don't understand this either.  Why would you want 3 ways to open a
> > file?  Remember, you can always load the file into any program you
> > want.  This is just setting the defaults for programs that want to
> > know how to open the file without popping up some unfriendly dialog.
> 
> Well, in the example above, I am dealing with a PHP file.  The example is
> poor, but representative.  Imagine it's a standard HTML file.  Why would I
> want to have 2 ways to open it?  Well, one would be to edit it.  Another
> would be to view it.  Maybe I want to view it with multiple browsers for
> compatibility's sake.  Maybe it's under CVS as well.  I guess that would
> go under "Actions", but I would definately want to see how it looked under
> multiple browsers. 
> 
	This is an extremely valid point to bring to bear, and should not be
ignored. This is one of the main reasons, at least I thought, for the whole
point of metadata. Christopher's description is very OS/2 like, and that's a
good thing.

> What it sounds to me like you suggest is this:
> 
> Gnome.Open: "netscape,mozilla,gzilla,kfm"
> 
> And then expect any client program to know that this is a comma seperated
> list.  What I think would be better (if that is the case) is:
> 
> Gnome.Open.0: Gnome.Open.2  (or just '2', with Gnome.Open implied)
> Gnome.Open.1: netscape -file %f
> Gnome.Open.2: gzilla -file %f
> Gnome.Open.3: emacs %f
> ...etc
> 
	Absolutely. I believe that this is definitely more manageable, and
understandable in the long-run. Perhaps because I'd expect that dealing with
SNMP quite a bit, it's more natural for me.

> Let's follow instead OS/2: There's a default action
> (double click) and custom actions (right-click).  Except, under OS/2, each
> custom action also has a default action, and a list of additional actions.
> If you haven't seen, the menu looks like:
> 
> +----------+
> | Open [>] |
> | Print    |
> | ..etc... |
> +----------+
> 
> Clicking "Open" would open it with the default Open method.  Clicking the
> boxed arrow (boxed arrows indicate a default method exists) bring this up:
> 
> +----------+
> | Open [>]+----------+
> | Print   | View     |
> | ..etc...| PMView   |
> +---------| ImgEdit  |
>           | Netscape |
>           +----------+
> 
> This is a *very* nice, and flexible system.  Worth duplicating.
> 
	We're looking to take the best from everyone, correct? OS/2's
workplace shell was the most elegant UI I've had the pleasure of working
with. It was consistent. It was flexible. And it was extensible. Three very
powerful attributes to combine.

	There is a file-manager that implements such an
enumerated-metadata/feature object menu for GTK already. It's NeXT-ified.
It's called Workplace. Perhaps some people should gander at that to take a
look at what's going on for a filemanager, and how the metadata scheme
outlined above, and implemented in OS/2 works and looks. The URL for
Workplace is - http://www2.osk.3web.ne.jp/~hideki70/

	-j