Re: DogCows or Polymorphism in the Hurd

[Bas Wijnen]

On Thu, Feb 02, 2006 at 01:56:50PM -0500, Marcus Brinkmann wrote:
> here is a small issue to ponder.  I'd like input on this.
> 
> However, it happens that in Unix, Directories and Files are not only
> very distinct objects, but they are also understand by a wide range of
> applications simultaneously.  Ie, many applications look at a node in
> the filesystem, decide if it is a file _or_ a directory, and then take
> an appropriate action.  All applications that can traverse a filesystem
> belong into this group, for example ls, rm, grep, find, etc.  This is
> the most prominent group, but I would expect there to be isolated cases
> of other applications that do this (maybe Apache?  Input welcome here).

Huh?  Why?  I'd say it's quite clear that there is a huge number of
applications which fall into this category.  Everything that has a file->open
dialog for example.  This group is so large that IMO it's undoable to make a
(possibly small) change in all of them.

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

This sounds good.  I think I would like to have the creation of the nodes with
other facets (so the creation of "foo" when "foo.tar.gz" exists) explicit.
That is, the user has to do it.  Otherwise there will be too many name space
collisions.  For example, it is usual that a foo.tar.gz unpacks a directory
called foo and files inside it.  If that directory and those files already
exist, strange things will happen when a script unpacks it, possibly removing
the directory first.

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

I agree with Shapiro that leaving it to the user is not lame at all, but
preferred.  It would be nice if the facets could be reached without explicit
creation of the nodes, though, but it shouldn't collide with the namespace
IMO.  Perhaps we can reserve a character for it, and name the facets of foo.gz
"foo.gz:raw" and "foo.gz:contents".  Note that this is an example where saying
"foo.gz:file" isn't very clear.

> * What are compelling use cases for hybrid types?

Any archive formats (including some image formats like tiff), many image
formats (layers, thumbnails, perhaps even colourmaps as a facet), compression
formats, text files(?) (auto-convert newlines to the system type).  The
possibilities are endless.  Anything for which one might want to write a
translator could be achieved with it.  And what's very good: one file can have
several translators bound to it simultaneously (and still be accessible in raw
format as well).

> * How severe are the confusions in the POSIX world introduced by hybrid
> types?

We need to make sure that POSIX programs don't notice it.  We cannot go and
change all POSIX programs.  For them, we have to design a system to reach the
facets without them noticing it's just the same file.  This may or may not be
the same system which is used by programs which do know about the facets.

> * How complex is the problem how hybrid types should be perceived by
> legacy applications?  Is it multi-dimensional and/or context-sensitive?
> Are there reasonable default resolutions?

There are no reasonable defaults, and the decision should IMO be up to the
user.  That makes it pretty simple from a programmer's point of view. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature