The Polycast Interface

Introduction

In the current Hurd, all fs objects implement both directory and file methods. This means every program that accesses a file object has to decide whether to treat it as a file or a directory. This is no problem for programs that only know about files or directories, but there is a wide range of programs that understand both files and directories simultaneously (e.g. rm -R), and they are confused when they see objects that are files as well as directories. This causes erratic behaviour. For example, "grep *" will search through the binary content of directories (because it treats them as files).

Sometimes, the file and directory interface are refered to as ``facets'' of the object.

The Problem

The problem is much worse than it might look like. Consider the case where one translator might reasonably implement two or more file interfaces, like a translator that simultaneously presents a .tar.bz2 file view, a .tar.gz file view and a directory view. Then you have a fundamental semantic issue:

A method call in isolation has no meaning. It can only be interpreted in the context of a particular interface.

A Solution

The solution is simple: whenever a method is invoked, the interface has to be known. This implies two things: a) we do not use multiple inheritance and b) support for some sort of ``casting'' is needed. For illustration, look at the inheritence graph for an object that provides both directory and file methods:

file dir
 \   /
dir_file

This graph can be converted into one using only single inheritence:

  poly_type
  \    /
file  dir

Where poly_type provides the methods get_supported_types() and get_facet(type) for casting: get_supported_types returns a list of types which this object can be viewed as. get_facet 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.

To give another example: the translator that provides .tar.bz2, .tar.gz and dir views would use the following inheritance graph:

     poly_type
       /    \
     file   dir
      /   \
tbz_file tgz_file

tbz_file and tgz_file do not provide new methods, they exist only to distinct interfaces.

Usability Considerations

In order for the polycast interface to be useful, it has to work together with legacy applications (that are unaware of it). As either the PowerBox or the shell grant authority to applications, there can be some private agreement between the user and these components on how to express different interfaces of objects. For example foo:as_dir could designate the directory facet of objecte foo. Also, different interfaces could be bound to different different names (either automatically or explicitely)