[Top][All Lists]

[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: Tue, 27 May 2008 19:23:49 +0300


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

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.

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

As far as I can understand, there won't be a file with a dictionary of
shorthand translator names (like I suggested in the first message), instead
there will be links with shorthand names, pointing to the required translator;
do I get it right?

However, the matter about ignoring some translators ('-u', for instance) is
a bit foggy for me. Do you mean that these should also be symbolic links?
I thought, it would be the job of the proxy filesystem to parse the '-' before
the names of translators... And if not, when we stack a '-gunzip' translator
upon a 'gunzip' translator, don't we get into redundancy somehow? By the
way, it seems to me that if it would be possible to ignore only the whole stack
of translators, this problem will dissolve.

Just a few hours ago such a question occurred to me: should the proxy
filesystem pay attention to the translators that had been set explicitly (via
settrans) before the proxy was loaded? I mean, should they be included in
the translator stack? Maybe, at startup, the proxy filesystem will go through
all files in the directory it is set upon, and, for each entry, remove the
translators found and include these translators in the translator stack
within the proxy.


reply via email to

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