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-
