On Fri, May 30, 2008 at 6:32 AM, <
olafBuddenhagen@gmx.net> wrote:
> 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?
That would be one of the implementation methods I suggested: Links to a
common filter translator. The script variant might be more elegant,
though...
I'm very sorry, but I feel completely lost :-( As far as I can get, the '-u'
filter should show the file/directory on which it is applied without any
archive translators. Does it mean that, when the node 'file,,-u' is
accessed, the proxy filesystem should generate a virtual node and
stack upon it all translators which precede the 'u' translator? I'm trying
to say the following thing: suppose there are the following translators
on 'file': x,u,y,z. When I ask for 'file,,-u' should I get the file 'file' with
only 'x' set upon it?
By the way, could you please suggest an idea where I can find out
how to list the entries of a stack of translators? Is showtrans with its
single file_get_translator call relevant in this case?.. Actually, I should
start with the question: should the proxy create its own stacks of
translators or just stack active translators?.. At the moment, I think the
proxy should create its own stack, but I'm not sure...
I think fetching the list of translators will be needed when the proxy
will be told to ignore some of the static translators.
When you say scripts, do you mean bash scripts or other scripting
languages? What really leaves me confused is how the interaction
between the proxy filesystem and the script should take place...
> And if not, when we stack a '-gunzip' translator upon a 'gunzip'
> translator, don't we get into redundancy somehow?
I don't see any redundancy...
I didn't suppose that translators could be _stacked_ or _executed_.
As far as I can get, executing a translator implies that it is not stacked
anywhere, doesn't it? I was thinking about the stack containing a
'-gunzip' upon 'gunzip'...
The example shows a real problem though: For "-gunzip" applied this way
to take any effect, the "-gunzip" translator must be executed *before*
opening the underlying node -- before any static translators that might
be present on the node get traversed. When applying a "normal"
translator like gunzip on the other hand, it should be simply be stacked
on top of anything that might already be present, just like stacking
static translators. Not sure about the best behaviour when applying a
magic translator like "u" or "-u" recursively -- in this case, I'm not
sure it's necessary to apply it before opening the node; but on the
other hand it shouldn't hurt to do so...
Am I right when I infer from these words of yours that there is no way
to ignore a translator which has been traversed already?
> 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?
Yes of course -- that's what I've been referring to as "static
translators"!
I wonder now, what did you think I meant by "static translators", if not
that?...
> 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.
Again, "remove" is a rather ambiguous term in this context; I'm not
quite sure what you mean here -- I hope you don't think of actually
removing them from the underlying filesystem?...
Actually, I don't understand at all what you are getting at in this
paragraph :-(