[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Namespace-based translator selection; project details
Re: Namespace-based translator selection; project details
Tue, 10 Jun 2008 21:19:35 +0200
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
> 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
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.
- Re: Namespace-based translator selection; project details, olafBuddenhagen, 2008/06/03
- Re: Namespace-based translator selection; project details, Sergiu Ivanov, 2008/06/03
- Re: Namespace-based translator selection; project details, olafBuddenhagen, 2008/06/07
- Re: Namespace-based translator selection; project details, Sergiu Ivanov, 2008/06/07
- Re: Namespace-based translator selection; project details,
- Re: Namespace-based translator selection; project details, Sergiu Ivanov, 2008/06/11
- Re: Namespace-based translator selection; project details, olafBuddenhagen, 2008/06/17
- Re: Namespace-based translator selection; project details, Sergiu Ivanov, 2008/06/18
- Re: Namespace-based translator selection; project details, olafBuddenhagen, 2008/06/18
- Re: Namespace-based translator selection; project details, Sergiu Ivanov, 2008/06/22