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

[Marcus Brinkmann]

At Thu, 9 Feb 2006 10:28:47 +0100,
Bas Wijnen <address@hidden> wrote:
> > > 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.

Why don't you like them?  I would like to hear your concerns.

Note that directories are going to be implemented by their own server,
and are linked into other directories the same way that files are.

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

Ok.  I think you still have a misconception: _Everything_ is going to
be a translator :) "Files" are objects provided by the "file"
translator.  We want to remove the difference between files and
translated files.

Ie, there won't be any need to create an empty file on which you
install the translator.  Instead, you install the translator by
linking it into a directory under a (potentially new) name.

The reason this works is that in a persistent system with a directory
server, you don't need to create any "inode" in the "filesystem" with
which a translator is associated.  This is because there is neither a
filesystem nor inodes.

> > > 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)?

I am not sure there is.  I wrote this paragraph before reading on, and
then just left it in, because I was not sure if this is what you
meant.  If you don't see a difference, then there is none :)

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

Then there is a difference.  In my model, the shell would use
something like ~/.shell/cache/... to create its "private" name space.

I am not sure this is really necessary.  Maybe it isn't, if all calls
to "open" can be traced to the shell, which knows about its private
bindings.  Then magic filenames that do not actually exist in the
directory servers could be used.  In any case, this is a minor detail
that should be resolved by what is practical to implement.

Thanks,
Marcus