Re: DogCows or Polymorphism in the Hurd

[Ognyan Kulev]

Marcus Brinkmann wrote:
> All objects are derived from a polytype class, which provides the
> following interfaces:
> 
> error_t poly_get_supported_types (obj_t obj, type_spec_t types[]);
> error_t poly_get_facet (obj_t, type_spec_t new_type, out: obj_t
> new_obj);

> Using the poly-type approach would remove all ambiguities: Applications
> would either see a file or a directory, but not both.  Applications who
> _know_ about hybrid types can use the new functions to switch facets
> explicitely.  If a user wants to use an application with a hybrid type,
> he will have to make his intent explicit by providing the node with the
> right facet type to the application.

I haven't catched up on this topic yet, but Hans Reiser has similar
problem with his reiser4 and multiple streams for one file:
<http://www.namesys.com/v4/v4.html#files_dirs>.  Perhaps it's worth to
learn what reiser4 does about it.

I remember that there was some proposal in POSIX to handle metadata as
files by using special file name component "..." (3 dots), e.g.
file/.../stat/mtime is file with last modified time. (Example is mine
and I don't know if the proposal was exactly for that.  The same applies
for the other examples in this mail.)  Anyway, this "..." was rejected,
but it could be used to access facets of any file (or directory).  So
directories could become real directories and not files in the Hurd and
their raw content may be accessed only by something like "dir/.../raw".
 Extended attributes can be accessed by this file thing too.  The tar.gz
case could be something like "package.tar.gz/.../facets/untar".

Of course, there are problems with this:

1. "..." becomes special file name component and can't be used for
anything else, just like "aux" in another OS.

2. Some of these /proc-like files has no inode number and this may
impose significant problems.

Regards,
ogi