On Fri, May 23, 2008 at 1:07 PM, <olafBuddenhagen@gmx.net
> If the user tries to access 'file1,u' a second time, nothing willThere is a very fundamental misunderstanding here: The namespaced-based
> change, because a translator will have already been set on 'file1'.
> Stacking of translators should be done in an explicit form, like
> 'file1,u,x' (x might mean xmlfs). When the user tries to access
> 'file1' , the translated version will be accessed.
translator selection is *not* meant as a replacement for settrans.
Rather, the idea is that you get the file in a translated form *without*
setting a translator permanently. The file itself doesn't change.
There is however some relation to static translators: One of the
purposes of the namespace-based selection is to be able to choose
between the translated and untranslated forms of a node that has a
static translator set.
The idea is much clearer for me now :-) As far as I can understand, the
namespace-based translator selection will _not_ modify the filesystem
permanently. Instead, it shall allow dynamic adding and removal of translators.
Frankly speaking, this idea looks very beautiful to me, but also I feel quite
at a loss as to the means by which the implementation of such functionality
will be done :-( I will dig as deep as I will able to to obtain the required
> For example, I think it will be quite comfortable if the user couldLayering on top should actually be the default action. Any static
> _add_ a translator to the stack, without specifying every single
> translator. Then, the user could write 'file1,+x' , if they have
> already accessed file 'file1,u' before.
translators present should only be ignored if explicitely requested.
Could the user request the removal of a static translator before adding
another one using the following syntax: 'file1,,-u,+x' ?
> If the user would like to create a file with commas in the name, they[...]
> will have to escape the comma, like here: 'Andrew\,Jane\,Mary.jpg'
The answer to the latter actually follows from the former paragraph: I
want to avoid any clashes with normal file names as well as possible.
There are several problems with the escaping scheme you suggested. For
one, names containing special characters are usually generated
implicitely by the software, not explicitely specified by users.
Another problem is that now you have given `\` a special meaning too.
Does it need escaping as well now?
I thought about it quite a bit, and arrived at the conclusion that the
only way to deal with this is to use something that is extremely
unlikely to occur in actual file names in the first place. At the same
time, it should not contain any characters that have special meaning for
the shell, to avoid major inconvenience. ",," is the simplest string I
could come up with that seems to fulfill both conditions.
I see now. However, a thought keeps coming to my mind: what if the user
would like to create a file with ',,' in the name?
> Somewhere in /etc there should reside a file containing the shorthandMaybe that's obvious, but I think it's important to point out that full
> names for translators. Of course, not only one-character names will be
names and even full path specifications should be allowed to be used as
Oh yes, I was thinking about that, too :-)
As for the shorthands, it's a tricky business, to come up with a
mechanism that is both transparent and powerful. It's not quite trivial,
as many shorthands do not name a single specific translator, but rather
a whole class: "u" for exapmle can be gunzip, bunzip2, unlzma (or
whatever it is named) etc.
It appeared to me just now that the simplest and most powerful way to
achieve this is simply to create real translators (multiplexors more
precisely) under the short names, which invoke the actual translators as
needed. It requires no special mechanism, and allows these shorthand
translators to implement any policy they see fit. In fact, this should
allow implementing most of the special syntax bits externally, reducing
the main namespace proxy to the very core functionality :-)
Multiplexors are indeed a very flexible mechanism, and they look as
flexible as the Hurd itself :-) It seems to me, however, that there will
still be a need for shorthands for the names of particular translators
(for example, 'gu' for gunzip) in the situations when these particular
translators will have to be removed recursively from some files in a
directory. Do I get it right?