Merge branch 'master' into external_pager_mechanism

Conflicts:
	microkernel/mach/external_pager_mechanism.mdwn

1 files changed, 82 insertions, 0 deletions

diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn
new file mode 100644
index 00000000..67e3fc28
--- /dev/null
+++ b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn
@@ -0,0 +1,82 @@
+[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled
+[[GNU Free Documentation License|/fdl]]."]]"""]]
+
+[[!meta title="Namespace-based Translator Selection"]]
+
+The main idea behind the Hurd is to make (almost) all system functionality
+user-modifiable ([[extensible_system|extensibility]]).  This includes a
+user-modifiable filesystem: the whole filesystem is implemented decentrally, by
+a set of filesystem servers forming the directory tree together, a
+[[hurd/virtual_file_system]].  These filesystem servers are called
+[[translators|hurd/translator]], and are the most visible feature of the Hurd.
+
+The reason they are called translators is because when you set a translator on
+a filesystem node, the underlying node(s) are hidden by the translator, but the
+translator itself can access them, and present their contents in a different
+format -- translate them.  A simple example is a
+[[gunzip_translator|hurd/translator/storeio]], which can be set on a gzipped
+file, and presents a virtual file with the uncompressed contents.  Or the other
+way around.  Or a translator that presents an
+[[XML_file_as_a_directory_tree|hurd/translator/xmlfs]].  Or an mbox as a set of
+individual files for each mail ([[hurd/translator/mboxfs]]); or ever further
+breaking it down into headers, body, attachments...
+
+This gets even more powerful when translators are used as building blocks for
+larger applications: A mail reader for example doesn't need backends for
+understanding various mailbox formats anymore. All formats can be parsed by
+special translators, and the mail reader gets the data as a uniform, directly
+usable filesystem structure. Translators can also be stacked: If you have a
+compressed mailbox for example, first apply a gunzip translator, and then an
+mbox translator on top of that.
+
+There are a few problems with the way translators are set, though. For one,
+once a translator is set on a node, you always see the translated content. If
+you need the untranslated contents again, to do a backup for example, you first
+need to remove the translator again. Also, having to set a translator
+explicitly before accessing the contents is pretty cumbersome, making this
+feature almost useless.
+
+A possible solution is implementing a mechanism for selecting translators
+through special filename attributes.  For example you could use
+`index.html.gz,,+` and `index.html.gz,,-` to choose between translated and
+untranslated versions of a file.  Or you could use `index.html.gz,,u` to get
+the contents of the file with a gunzip translator applied automatically.  You
+could also use attributes on whole directory trees: `.,,0/` would give you a
+directory tree corresponding to the current directory, but with any translators
+disabled, for doing a backup.  And `site,,u/*.html.gz` would present a whole
+directory tree of compressed HTML files as uncompressed files.
+
+One benefit of the Hurd's flexibility is that it should be possible to
+implement such a mechanism without touching the existing Hurd components:
+Rather, just implement a special proxy, that mirrors the normal filesystem, but
+is able to interpret the special extensions and present transformed files in
+place of the original ones.
+
+In the long run it's probably desirable to have the mechanism implemented in
+the standard name lookup mechanism, so it will be available globally, and avoid
+the overhead of a proxy; but for the beginning the proxy solution is much more
+flexible.
+
+The goal of this project is implementing a prototype proxy; perhaps also a
+first version of the global variant as proof of concept, if time permits. It
+requires good understanding of the name lookup mechanism, and translator
+programming; but the implementation should not be too hard. Perhaps the hardest
+part is finding a convenient, flexible, elegant, hurdish method for mapping the
+special extensions to actual translators...
+
+Possible mentors: Olaf Buddenhagen (antrik)
+
+Exercise: Try to make some modification to the existing unionfs and/or firmlink
+translators. (More specific suggestions welcome... :-) )
+
+*Status*: Sergiu Ivanov has been working *voluntarily* on
+[[namespace-based_translator_selection|scolobb]], as an inofficial GSoC 2008
+participant! Not all the desired functionality is in place yet; work is
+ongoing.