Hi, On Sat, Jun 07, 2008 at 11:21:10PM +0300, Sergiu Ivanov wrote: > On Sat, Jun 7, 2008 at 3:13 PM, <[EMAIL PROTECTED]> 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-
