Re: DogCows or Polymorphism in the Hurd

[Bas Wijnen]

On Mon, Feb 06, 2006 at 11:15:06PM +0100, Marcus Brinkmann wrote:
> 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:
> (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...).

Yes, but we will need to supply a POSIX environment as well, which doesn't
work that way (at least for a probably quite long transition period).  Denying
them the multi-facet view is a severe limitation for them, which should be
avoided if at all possible.  I don't think requiring a change to all of them
to use the shell as a proxy for opening files is doable.  It would be possible
to move that into libc, but that would result in a very hacked-together
interface (think of any program opening a lot of files, such as find).

> > > 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 would consider a setting "open under name 's/(.*)\.tar\.gz/\1/'" in some
config file of the graphical shell.  That's enough "leaving the decision to
the user" for me: the user chooses the name, and the user decides to bind it
(by double clicking on the file).  An other question is if it should unbind
when leaving the directory.  I think it probably should.  However any other
process which entered the binding should have added the "reference count", and
it should only be unbound when as many processes have unbound it as have bound
it.

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

It could do this, but I think it would be useful to have it at least reachable
for other (POSIX) applications.  It's useful to right-click on a file and say
"open with".  Then the program which opens the file must be able to reach it
by path (because that's the only way most POSIX applications understand).

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

If different filenames are used for different facets (which is required for
POSIX applications), then in principle this could be done with translators.
The only difference is that (semi-)automatic binding of the appropriate
translators to each file.

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