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

[Bas Wijnen]

On Thu, Feb 09, 2006 at 04:14:14AM +0100, Marcus Brinkmann wrote:
> Hi,
> 
> some clarifications:
> 
> At Wed, 8 Feb 2006 22:41:59 +0100,
> Bas Wijnen <address@hidden> wrote:
> > I had not considered the option of one facet being opened more than once
> > using different file names.
> 
> A directory is a mapping from (arbitrary) strings to objects.  There
> is no restriction on the object mapped.  You can map the same object
> many times in a directory ("hard links").

Yes.

> > 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.
> 
> A symlink is a different feature, but also possible.

I don't like hard links to directories, but of course that would be the most
logical equivalent of two files binding the same (directory-implementing)
facet.

> > 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.
> 
> Translators are not called facets.  They are two quite different
> things.  Translators are simply object servers, preferably ones that
> speak the directory and/or file protocols.

Right, sorry about being unclear.  What I meant was that for this specific
case, a binding of a facet to a filename can very well be implemented as a
translator.  Thus the problems that find has with following translators are
also present when find goes "into" facets.

> > 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.
> 
> There is a middle ground: The names are user-defined, but the file
> explorer (ie, the user shell) can create new implicit bindings, under
> names well known following a convention, or in its own private name
> space.  This seperates the policy of implicit bindings from the
> underlying system interfaces.

What's the difference with my proposal (explicit binding where the graphical
file browser has a default)?

> > 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_.
> 
> I am not sure what "within that program" means, because the name may
> have to be exposed.  The example here would be the setup.exe case that
> Jonathan described.

"Within that program" means that this default is not valid anywhere else.  If
I'm in bash, I need to do the explicit binding.  Of course once the binding is
made, it stays there until it is removed.

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