On Mon, May 26, 2008 at 8:49 PM, <
olafBuddenhagen@gmx.net> wrote:
As I already suggested, at least for the prototype, I believe it can be
implemented as a proxy which mirrors the underlying file system, and
does it's magic whenever a virtual file with the special suffix is
accessed.
I also already suggested studying unionfs and/or firmlink as examples of
translators that do some kinds of namespace proxying.
OK. I'll read the code of these translators.
> Could the user request the removal of a static translator before
> adding another one using the following syntax: 'file1,,-u,+x' ?
Yes, except that the '+' is not necessary, as it's the default action
anyways :-)
Oh, sure. That's clear for me now.
Thinking of this, I'm not sure whether in the case of a translator
stack, it's actually possible to ignore just some of the layers...
Perhaps it's only all or none. That would introduce some questions how
to handle translator stacks...
By the way, which would be the average size of a translator stack in your
opinion? I don't think my assessment of the situation is really well-founded,
by I suppose that there won't be really much translators. And if so, having
just the two options "all or none" seems sufficient.
> > I want to avoid any clashes with normal file names as well as
> > possible.
> 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?
Well, tough shit I would say... :-)
Again, I picked something a user is extremely unlikely to want to
create, specifically to avoid this situation. We could try to come up
with some escaping scheme (e.g. ",,," to mean ",,"), but I'm not sure
it's really useful.
OK. I think I'll forget about this matter for the time being :-)
> 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.
I'm not sure a shorthand is really necessary here: If someone has such
specific needs, he can just as well use the full name, i.e.
"foo,,-gunzip/".
Oh yes, indeed :-)
As for the implementation, we would have a translator named "-gunzip",
which would again proxy the underlying directory tree, but ignoring any
gunzip translators present.
Of course, we do not want to implement the "-" variant of each
translator explicitely. Rather, we can just make them all links to a
generic filter translator, which always skips the translators matching
the invocation name (without the "-" of course), i.e. if invoked as
-gunzip it would skip any gunzip translators, as -mboxfs any mboxfs
translators etc.
[...]
Also, many of the shorthand translators can in fact simply be links to
the normal forms, e.g. "x" for xmlfs. Only the magic ones like "u" need
a more explicit implementation.
That's the beauty of this approach: We only use standard mechanisms, and
thus can implement the individual shorthands whatever way we want :-)