Re: DogCows or Polymorphism in the Hurd

[Jonathan S. Shapiro]

On Sat, 2006-02-11 at 00:38 +0100, Patrick Negre wrote:
> Ok, but i want my ls command to list files, i will be very confuse if one of 
> my file is listed as many time as the number of translators set on it.
> I expect my command "rm f" to remove a file not a view.
> 
> I want my system to be sufficently smart to understand that "cd foo.tar.gz" 
> mean i wanna browse foo.tar.gz, and after execution i expect   to be in 
> "foo.tar.gz/" as i asked. ( under the condition foo.tar.gz is browsable .
> 
> I expect, when i command a "cat whatever", that the system will understand 
> that i wanna access "whatever" as a file.
> 
> I want to have a simple way to access a file with a non default view, like 
> ( it's an example ) : "cat whatever::binary"

Patrick:

I understand that you believe you want these things. Unfortunately, you
will find that the consequences of *having* these things are an unusable
and inconsistent system.

> Tom Bachmann wrote:
> > the problem is that POSIX only specifies one reserved character, '/', 
> > and thus foo.tar.bz2:as_dir is a valid name. So such a file could exist.
> Does POSIX specify anything about polytype files ?

POSIX does not, but it is not important. In the polytype case, it is a
matter of adding new system calls, which is okay. In the namespace case,
we would be required to violate the POSIX rules.

> All this can't be possible if the system don't handle unspecified access, as 
> the POSIX open(), or stat().

I am not clear what you mean by unspecified access. In the polytype
proposal, all access is specified and straightforward.

> To handle this access, unspecified access can be mapped to a default 
> translator.

I think this is the main source of confusion. There is no "mapping to a
translator" in POSIX. There is only "opening a facet that is bound to a
name".

The knowledge of polytype behavior is necessarily restricted to new,
polytype-aware programs.

> Absolute and comprehensive path like "./foo.tar.gz::gzip/f.xml::xml/value" 
> are 
> possible and share by every applications, aware or not of polytype 
> possibilities.

This violates existing standards. We need to understand if it may break
existing applications.

> This is my simple user proposition.

Well, it is your proposition. In practice, I don't think it is simple.

However, I do not wish to be entirely negative. There are some very
important things that we have all agreed on in this discussion:

  1. We want polytype, not DogCow
  2. There are several views about name binding, but all of them
     associate names with facets in 1:1 fashion. Some are more dynamic
     than others.

Given this, I want to suggest that we have enough information to choose
a design strategy. Also, I want to suggest that our preferences will
change with experience, and we should not obsess about them now.


Jonathan