Hello,
On Mon, May 26, 2008 at 8:49 PM, <[EMAIL PROTECTED]> 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 :-)
>
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.
scolobb
