Re: DogCows or Polymorphism in the Hurd

[Tom Bachmann]

Marcus Brinkmann wrote:
> These applications face a problem in the Hurd: They will see objects
> that look like Directories _and_ like Files.  This causes erratic
> behaviour.  For example, "grep *" will search through the binary content
> of directories

Why the hell directories provide their binary content?

> (because it treats them as files). 

Yes. But grep usually doesn't choose the files to examine at all. The 
user/shell does.

> One suggestion was
> that we add extra options to such programs to control how hybrid types
> should be treated by the application.
>
> So, here is the deal: Either we convince ourselves that such erratic
> behaviour is isolated and can be fixed by proper defaults and making
> minor modifications to existing programs.  Or we find out that in
> general this problem is too hard to fix: How an application should treat
> a DirFile may be context-sensitive and depend on the exact type of the
> object, the intent of the application ("find" used for backup vs "find"
> used for locatedb), or even the intent of the user. 

This is true, sadly.

> In this case, it
> may be better to drop the notion of "DogCows", and make the _current_
> facet of the object explicit in its type.  Here is how this can be done:
>
> 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);
>
> The function poly_get_supported_types returns a list of types which this
> object can be viewed as.  Iow: these are the facets provided by this
> object.  poly_get_facet is a bit like a "cast": It returns a new object
> with a new type, but the object is, at the server side, intimately
> related to the original object with the original type.  For example,
> changes to the one object may become visible in the other object in some
> way.
>
> What would this mean for our tar.gz example?  It would mean that a
> translator implementing a tar.gz feature would either be seen as a
> tar.gz file, _or_ as a directory to the root of the archive, but never
> both with the same object.  In particular, the tar.gz file and the tar
> root directory would get different names in the directory hierarchy.
> For example, the tar.gz node could be called "foo.tar.gz" and the
> archive root dir could be called "foo".

I guess you mean the logical hierarchy? So that what e.g. ls shows us? 
Because this poly-type object is still one file, and we do not even have 
a reliable way to insert the new logical files into the hierarchy.

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

What I do not understand is what applications without knowledge of this 
approach. They would see objects that neither provide directory nor file 
semantics.

> It sounds a bit lame to leave the problem which facet is the right one
> to use in the context of POSIX applications to the user.  But it may be
> that this is the best we can do.  If it is the best we can do, I think
> the poly-type approach provides a very clear and flexible solution to
> this problem, while preserving the ability to implement and use hybrid
> types.
>
> Some questions:
>
> * What are compelling use cases for hybrid types?
> * How severe are the confusions in the POSIX world introduced by hybrid
> types?

To my view: great.
I do not yet fully understand this approach, but either

all facets are listed in the real hierarchy (though I do not know how 
this would be possible).
In this case your grep example still would not work.

or
only the polytype object appears in the real hierarchy and the facets 
only shown by commands like ls that know about hybride objects.

This approach sounds better for me, but still there are complexities:
If you give such a "logical file name" showed by ls to you to an 
application unware of hybride types, it will fail.
A new application that directly takes capabilities as arguments does not 
even have to care about hybride types, as the shell will have to 
translate the logical file name into a real capability.

Still we have the problem with legacy apps. I thought about this too. If 
we take together a novel shell that can translate logical file names, a 
special implementation of the open function and the user/shell model 
described by jonathan (I do not know exactly how you called it), it can 
be done:
open has to mirror the call to the shell, and the shell then can return 
the right capability (and it can also do whatever checks it wants, get 
ack from the user, ...)

> * How complex is the problem how hybrid types should be perceived by
> legacy applications?  Is it multi-dimensional

What means multi-dimensional here?

> and/or context-sensitive?

Of course it is context sensitive. Not only I want different 
applications to see different facets of the same object but also I want 
some all-in-one app to see different facets of the same file simultaneously.

> Are there reasonable default resolutions?

Possibly. E.g. the file view of a .tar.bz2 file would be default, I guess.

> Wuffmuuh!
> Marcus

I'm not really convinced, but it sounds nice.
--
-ness-