bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Namespace-based translator selection; project details


From: Sergiu Ivanov
Subject: Re: Namespace-based translator selection; project details
Date: Fri, 23 May 2008 18:50:47 +0300


Hello,

On Fri, May 23, 2008 at 1:07 PM, <olafBuddenhagen@gmx.net> wrote:
> If the user tries to access 'file1,u' a second time, nothing will
> 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.

There is a very fundamental misunderstanding here: The namespaced-based
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
knowledge.
 
> For example, I think it will be quite comfortable if the user could
> _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.

Layering on top should actually be the default action. Any static
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'
[...]
> I would also like to ask why the syntax file,,u is suggested here
> http://www.bddebian.com/~wiki/community/gsoc/project_ideas/ . I still
> don't possess enough Hurd experience to be able to apprehend fully the
> necessity of using two commas instead of just one.

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 shorthand
> names for translators. Of course, not only one-character names will be
> allowed.

Maybe that's obvious, but I think it's important to point out that full
names and even full path specifications should be allowed to be used as
well :-)

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?

scolobb


reply via email to

[Prev in Thread] Current Thread [Next in Thread]