Hello, On Fri, May 23, 2008 at 1:07 PM, <[EMAIL PROTECTED]> 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/<http://www.bddebian.com/%7Ewiki/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
