Re: Namespace-based translator selection; project details

[olafBuddenhagen]

Hi,

On Tue, May 20, 2008 at 09:46:16PM +0300, Sergiu Ivanov 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.
Permanetly setting a translator by accesing a file through a special
filename would be extremely awkward.

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.

> Whenever the user wants to get the untranslated version of file1, they
> will be able to get it using the name 'file1,0'. To remove the top
> translator in the stack, the user will write 'file1,-'.

It is more important to be able to skip specific translators given by
name, e.g. file1,,-u to skip any unzip translator present. If it's at
the top of a stack, only this translator is skipped; otherwise, also all
other ones on top of it.

Why this is more important quickly becomes obvious when thinking of
recursive use: You can for example use foo,,-u/ to access the directory
tree below foo/, ignoring any unzip translators that might be present;
but other translators are preserved. foo,,-/ on the other hand wouldn't
be helpful.

> 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.

> 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. RCS/CVS
for example uses names ending with ,v in the repository. Wget can create
a file containing ',', when downloading a file containing ',' in it's
name. And so on. You can't hack all these programs to escape any ','...

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.

> 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 :-)

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 :-)

-antrik-