Re: DogCows or Polymorphism in the Hurd

[Jonathan S. Shapiro]

On Fri, 2006-02-03 at 18:08 +0100, Tom Bachmann wrote:
> Jonathan S. Shapiro wrote:
> > If we cannot insert files, then the translator either needs to make the
> > directory appear to be read only or this bug needs to be fixed.
> > 
> 
> This cannot was more intended to be a "should not". It is still _one_ 
> file and I think making one file appear as multiple ones will cause more 
> troubles than it removes.

Not if the view is consistent. For example, adding files to the
directory view can be seen as appending a file to the existing archive.
Deleting can be handled the opposite way. As long as the illusion is
consistently maintained across views in some sensible fashion, I don't
really see a problem.

> Maybye we're speaking cross purposes and I just don't understand the 
> thing. Assume I move a .tar.bz2 file from some where into an empty 
> directory. Then I use my "completely-polytype-unawayre-ls", what will I 
> see? And will I see something different when using the hurdish ls. If 
> so, what and why?

What you will see is a single file "foo.tar.bz".

But if you now choose to browse this file through a browser, the browser
may choose to bind a directory-ish view under a new name. Or not.

If you want a pretty good example of how this works from the user point
of view, look at the Windows Explorer.

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

They will see whatever type was bound for the name they open. In your
example above, if they open foo.tar.bz, they will see a file. If a
translator has bound "foo" to a directory view on the same object,
attempts to open "foo" will see a directory.

> > This is not correct. Have a look at my ascii art (assuming it survived;
> > use a monospace font). In effect, you have a "file" object that has two
> > new methods:
> 
> So you, in fact, want to set a default facet (file)?
> At lest that's how i interpret your statement + this graph:
> 
>      FsObject
>       /   \
>      File Dir
>       \   /
>      FileDir

No no! The graph above is an example of what NOT to do!

The graph that I was referring you to was:

   PolyType
    /    \
  File   Dir

In this graph, foo.tar.bz would be bound as a File interface (more
likely, as a BzFile interface). foo would be bound as a Dir interface.
Given either, you can obtain the other *if* you are polytype aware.

There isn't any default. There is only the view that the user bound.

shap