On Tue, Jun 10, 2008 at 10:19 PM, <
olafBuddenhagen@gmx.net> wrote:
On Sat, Jun 07, 2008 at 11:21:10PM +0300, Sergiu Ivanov wrote:
> > Normal translators like "gunzip" would just use the underlying node
> > directly, forming an ordinary translator stack. Filter translators
> > on the other hand would use the additional interface to got the
> > untranslated node corresponding to the translated one they are
> > attached to, and work on that.
>
> Yes, that was my idea.
Ah. Seems I'm a bit slow :-)
No, not at all! I like very much the fact that you never leave things without
conclusions. I wish all people who taught me had expressed their
thoughts in such a clear way :-)
> Yes, it seems clear for me that a simple translator does not need to
> know whether it is set upon a virtual node created by the proxy or
> upon a "real" node. The more specific requests, like asking for the
> untranslated node, bother me. I'll try to figure out how to organize
> such communication.
I don't really understand. What is there to figure out?
Frankly speaking, I still have no idea as to the communication between
the proxy and the translators it loads. I suppose the proxy will have to
exhibit an interface in a .defs file, but I know very little about such
things yet. I hope my idea isn't completely wrong.
> > Note that the virtual node mirroring the original "file" node with the
> > static "x" translator applied (what you call "file,,x", though as I
> > explained above this is confusing), is actually created by the main
> > proxy, upon request from "-u". "-u" first opens a mirror of the
> > untranslated node, and then follows only the "x" translator, which
> > causes the main proxy to create another mirror, this time with the
> > "x" applied. "-u" then returns that as the result to be passed to
> > the client.
> >
> > When another filtering translator is applied, say "-foo", this one
> > will again ask for a mirror of the untranslated node, and check what
> > translators exist on it. It gets only "x" this time, as "x" is the
> > only translator present on the virtual node previously created. If
> > the filter rule of "-foo" says that "x" should be filtered, foo will
> > return a mirror of "file" without any translators; otherwise, it
> > will just again return the mirror of "file" with "x" applied -- the
> > very same (virtual) node it is attached to. In other words, "-foo"
> > won't change anything if the filter rule doesn't require skipping
> > "x"; it just passes through the previous node.
>
> Do I understand it correctly that after applying the '-u' translator,
> there will be two virtual nodes in the proxy filesystem, of which one
> will be mirroring the untranslated version of 'file' and the other
> will be 'file,,x'?
Not really. The one mirroring the pure untranslated "file" is used only
temporarily.
Do you mean that, after a filter translator has used the virtual node
mirroring the untranslated version of 'file', this virtual node should go
away? I thought it should stay for a longer time, so that it won't be
required to retrieve it anew when another filter translator is loaded.
All in all, three virtual nodes are involved: The one with all
translators present, to which "-u" is attached; the completely
untranslated one used by "-u" temporarily; and finally the one with "x"
attached, which is returned to the client.
Suppose the client accesses 'fie,-u'. The proxy will create the three
nodes you have named above and the client will receive the node
'file' translated by 'x' only. What shall the proxy return when the
client asks for 'file' simply? The node with translator 'x' only, or the
node with all translators ('x', 'u', 'y', and 'z')? I'd feel it natural if the
proxy would return the node with translator 'x' only and then it
somehow seems to me that we could dispose of the version with
all translators, so that there would remain only two nodes: the one
with 'x' attached and the completely untranslated node, used
temporarily by the filter.
Oh, and "file,,x" is still wrong :-)
Oh, you mean that 'file,,x' reads like 'attach translator "x" to node
"file"? Indeed, I've misused the notation again...
> > But if there is some standard way to ask any translator for the
> > underlying node, we wouldn't need the special interface. It would
> > simplify things.
>
> I'll try to find out whether such a possibility exists, but I'm afraid
> I'll fail... As usual, I can't even think of where to begin the
> search... :-(
The interface definitions (*.defs) are probably the best place to look.
I don't know which of them are relevant, thought... Perhaps fs.defs.