Re: Perils of Config Files (was DogCows or Polymorphism in the Hurd)

[Bas Wijnen]

On Wed, Feb 08, 2006 at 03:53:59PM -0500, Jonathan S. Shapiro wrote:
> Bas has proposed a design relying on external configuration files to
> decide what "facet" is the default when an object is opened.
> Specifically, he wrote:
> 
> > On Tue, 2006-02-07 at 10:24 +0100, Bas Wijnen wrote:
> > > > I would consider a setting "open under name 's/(.*)\.tar\.gz/\1/'" in
> > > > some config file of the graphical shell. 
> 
> And I responded:
> 
> > > Oh wonderful. 15 billion more things that won't get tested and make
> > > customer support absolutely impossible because the support agent cannot
> > > figure out what the hell the application is doing.
> 
> I can see from his reaction that I was excessively obscure.

I see from your reaction that I wasn't very clear either. ;-)

> Q6: Isn't it much simpler to bind each filename to a single facet?

I was indeed planning that.  All I was proposing was to let the user choose
the filename to use when the shell is about to open a file using a new facet.

I have never considered using the same filename to implement different facets
(well, at least not since it became clear that that results in unsolvable
problems).

I had not considered the option of one facet being opened more than once using
different file names.  I think this should be possible, and it should function
as symlinks (perhaps it should somehow also function as symlinks to find, so
it traverses only one of them.  Anyway, find will get in trouble if it follows
translators (which are now called "facets", and are limited to types which do
something to some related node) anyway.

To make things clear:
Assuming we want the facets bound to names in the file system, there are two
options:
- The names are fixed, and somehow system-defined (for example, the filename
  followed by a :, followed by a facet-defined part).  That results in names
  like foo.tar.gz:dir/bar.  The binding can in this case be implicit or
  explicit (implicit binding meaning that the facet-names always exist and
  don't need to be created.  The only way to get rid of them is to remove the
  file itself).
- The names are user-defined.  In that case binding cannot be implicit, of
  course, since the name is unknown until the (explicit) binding is done.

In case of explicit binding, there can also be an "unbind" operation which
(explicitly) removes the facet name.

My proposal was targetted at Marcus' comment, which was that explicit binding
was impractical, because users of graphical shells don't want to type in the
name of the binding, they just want to "right-click->open as dir" (or
something) on a tar file.  That can be solved by giving the facet name a
default _within that program_.

The proposal is not meant to change the system, only to implement explicit
binding in a way that the user of the graphical shell will hopefully find
intuitive.  Note that outside the shell, the setting has no effect at all.

I like the approach of user-defined names, because it's flexible (and it
doesn't reserve extra characters for filenames).  The proposal was only meant
to point out that this doesn't need to be as user-unfriendly as it may seem at
first.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature