Move `NextHurd' (and everything below) into `hurd/ng'.

1 files changed, 0 insertions, 52 deletions

diff --git a/NextHurd/ThePolycastInterface.mdwn b/NextHurd/ThePolycastInterface.mdwn
deleted file mode 100644
index 5d1fb8dc..00000000
--- a/NextHurd/ThePolycastInterface.mdwn
+++ /dev/null
@@ -1,52 +0,0 @@
-# <a name="The_Polycast_Interface"> The Polycast Interface </a>
-
-## <a name="Introduction"> Introduction </a>
-
-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.
-
-## <a name="The_Problem"> The Problem </a>
-
-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 name="A_Solution"> A Solution </a>
-
-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.
-
-## <a name="Usability_Considerations"> Usability Considerations </a>
-
-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)
-
-----
-
-see also:
-
-* <http://lists.gnu.org/archive/html/l4-hurd/2006-02/msg00002.html>
-* <http://lists.gnu.org/archive/html/l4-hurd/2006-02/msg00003.html>
-
--- [[Main/TomBachmann]] - 30 Apr 2006