Re: Namespace-based translator selection; project details

[olafBuddenhagen]

Hi,

On Sat, Jun 07, 2008 at 11:21:10PM +0300, Sergiu Ivanov wrote:
> On Sat, Jun 7, 2008 at 3:13 PM, <olafBuddenhagen@gmx.net> wrote:

> > Nevertheless, there is a lot of merit in your observation: I realise
> > now that there is really no reason to externally classify the
> > translators, and attach them them to a different node up front.
> > Instead, all translators could just be attached to the node with all
> > static translators present; and the proxy would provide an
> > additional interface an all the virtual nodes, explicitely allowing
> > to ask for the same node, but untranslated.
> 
> > 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 :-)

> > The communication channel is established the moment a translator is
> > launched: The translator is attached to the underlying node upon
> > startup. Part of this process involves the translator getting a port
> > to the node on the parent FS it is attached to. (The virtual node on
> > the main namespace proxy, in our case.)
> >
> > Most of the requests on this port are simply forwarded by the proxy
> > to the underlying "real" nodes, so it behaves just like the
> > translator had been indeed attached directly to the "real" nodes.
> > Some requests however are more explicitely handled by the proxy --
> > like for instance providing an untranslated (virtual) node
> > corresponding to the translated one...
> 
> 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?

> > I wouldn't write it as "file,,x", though -- this is too confusing.
> > The result of actually opening "file,,x" would be quite different:
> > It would stack a new dynamic "x" translator on top of the "file"
> > node with all it's static traslators present -- "x", "u", "y", "z",
> > and now another "x"...
> 
> OK, I will avoid such notation. I just wanted to use less words, but
> lost accuracy :-)

Well, I tend to think along these lines as well... But nevertheless it's
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.

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.

Oh, and "file,,x" is still wrong :-)

> In other words, the user of the proxy will think that translators 'y'
> and 'z' are gone for good, right? The proxy won't really care that in
> the underlying filesystem the node 'file' is translated by static
> translators 'x', 'u', 'y', and 'z', will it?

Yes, so to say. The client doesn't see the "u", "y", and "z" translators
at all -- it sees the node as if the translator never were present.

> > 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.

-antrik-