[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DogCows or Polymorphism in the Hurd

From: Tom Bachmann
Subject: Re: DogCows or Polymorphism in the Hurd
Date: Fri, 03 Feb 2006 09:42:37 +0100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051031)

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

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

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

Some questions:

* What are compelling use cases for hybrid types?
* How severe are the confusions in the POSIX world introduced by hybrid

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.

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]