l4-hurd
[Top][All Lists]
Advanced

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

Re: DogCows or Polymorphism in the Hurd


From: Marcus Brinkmann
Subject: Re: DogCows or Polymorphism in the Hurd
Date: Mon, 06 Feb 2006 23:15:06 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Fri, 3 Feb 2006 10:55:21 +0100,
Bas Wijnen <address@hidden> wrote:
> 
> 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.

If there is a file->open dialog, then the decision what filename is
treated as a file or a directory is made partly by the user.  But you
are right, the application actually has different GUI elements for
directories and for files.  I didn't think of file->open dialogs,
thanks for pointing this out!

(But then, in a POLA system you would probably move the file->open
dialog into the shell, reducing the number of affected applications to
one...).

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

Yes, choosing the names is a problem.  However, I am not sure you can
always leave this to the user.  There is a strong motivation to enter
tar.gz files automatically by double-clicking on them.  Asking for a
directory name would remove the transparency.  I have not thought
about this problem, but it seems to me that at least within the
interactive graphical shell there can be a strong convention.  In
fact, the shell does not even need to create the different facets in
the same directory as the "facetted" file---it can use a private
scratch area.

This is one area of the multi-facetted solution that would need to be
worked out.

Thanks for your input!
Marcus





reply via email to

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