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

[Marcus Brinkmann]

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

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

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

Facets are different interfaces to the same internal "object".  This
means that a translator implements one or more facets of an object.

Although in theory you can implement multiple facets of the same
object in different translators (server processes), by mutual
cooperation between these server processes, I would expect the usual
approach to be that all facets to one object are combined in one
translator.

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

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

Thanks,
Marcus