Re: metadata

[Christopher Curtis <ccurtis ee fit edu>]

On 15 Sep 1998, Tom Tromey wrote:

Sorry I'm not very clear...

Here is a feeble attempt to clarify.

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

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

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

If a client wants to figure out how to open the file, it would request
"Gnome.Open" and (well, I guess this could replace .Open.0) whatever key
this requested would be returned.  In the case above, the key value
stored in Gnome.Open.2 would be returned.  This way you can change
default associations without breaking other associations.  In addition,
then you would also need (aside from get_key()) a get_key_list() to return
all keys, preferrably as char *[] array.

If I'm not mistaken, this object model seems very heavily Win95 biased, at
least in this regard, and that model, imo, really sucks.  In Win95, for
instance, there's a default action (double click) and custom actions
(right-click).  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.

> >> "Gnome.Open.NeedTerminal" Boolean: if set, the program needs a
> >> terminal to run, false otherwise.
> 
> Christopher> Hmm.  Don't like it.  Don't know that I could come up
> Christopher> with anything better, but this seems like it should
> Christopher> belong in a set of flags.
> 
> This should be hidden in the program that is used to actually launch
> the program.  The actual edit request should happen via CORBA.

Well, this is true, but it would be nice to have some compatibility with
non-GNOME specific apps.

> Christopher> "Actions"?  I presume these are either global or
> Christopher> type-based?  Sounds okay (same arguments as above wrt
> Christopher> numbering).  How will they be overridden?  Eg, will you
> Christopher> be able to do a:
> 
> Christopher> *: Action.Print: "lpr -P$PRINTER $this"
> Christopher>  as defaults, and
> Christopher> *.a: Action.Print: "nm $this | lpr -P$PRINTER"
> 
> Metadata processing works in phases.  You can have metadata attached
> directly to a file, to a regular expression which matches files, or to
> a file's type.  There are also various ways of determining a file's
> type.

Sure.  But there was something in what was said that made me question if a
method could be overriden.  Taking the exact same example as above, would
Action.Print for *.a override Action.Print for *, or would it compliment
it?  That is, do I now have two ways to Action.Print *.a files, or do I
only have the most specific case?

> Christopher> If it's broken up on the granularity of an individual
> Christopher> file, does it go into the global frame or become a
> Christopher> Gnome.Action.Print...?
> 
> I don't understand this question.

I'm not sure I do in this context either, though I suspect I was wondering
where the actual data was going to be stored.  If it was with a database
for the object itself, or something broader in scope.  Not sure why I ask.

Christopher