Hello, On Sat, Jun 7, 2008 at 3:13 PM, <[EMAIL PROTECTED]> wrote:
> Note that the virtual nodes are always created on demand, the moment > they are accessed; so you would never actually create both variants up > front. But conceptually, you indeed could think of two virtual nodes > used alternatively... That's clear, the nodes will be created when required. > It seems to me that no actual classification of translators into > > normal and special should be done, I mean that all translators should > > be allowed to access both mirror nodes. Is it so, or do I overlook > > something? > > The bit you are overlooking is that a translator is attached to a single > node the moment it is started. It doesn't decide itself where it wants > to be attached... Hm, I really forgot that ... > 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. Thanks, by the way :-) > > As far as I can see, scripting languages are very popular nowadays. I > > do agree that shell scripts would be most appropriate for a simple > > launcher, but later it might prove useful to integrate some other > > scripting languages into the namespaced translator selection project, > > at least for the sake of attracting people :-) (Of course, I'm not > > even thinking of that before completing the basic framework) > > Well, this is really orthogonal. Of course one could use Flavio's Lisp > bindings to write "-u" for example -- just like for writing any other > translator... > The whole point of this idea is that all the special syntax, like "-u", > is provided by ordinary translators, and we can use any method we like > for the implementation of these :-) > Yes, indeed. Your idea is much more beautiful for me now than it was when I read the description for the first time :-) > > At the moment I don't have a clear idea of how to set up a proper > > communication channel between the main proxy and the special > > translators. > > 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. > > [...]In the end the user gets 'file,,x'. Right? > > 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 :-) > > What if I try to set another special translator on the resulting node? > > The special translator would probably like to perform the procedure > > described above, but there is only one virtual node 'file,,x' created > > by '-u' and no auxiliary mirrors. How shall the main proxy manage such > > a situation? > > Now it's getting really confusing... Maybe we should start drawing > pictures for illustration :-) I'll try to manage without pictures for now, but I like the idea very much :-) I have no idea though what you mean by "auxillary mirrors". I don't see > any problem with this situation; no need for any special handling... After reading the next two paragraphs I understood what my problem was. Fortunately, messy ideas in my head are gradually dying out. 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'? 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? > > Every translator knows the node it is attached to. I don't know > > > though whether there is any standard RPC that would allow to query > > > this information. If it turns out there is, this would actually > > > simplify things a lot -- "-gunzip" could just ask for the original > > > (untranslated) node under the static "gunzip" translator; no need > > > for special handling to make sure "-gunzip" gets active before > > > following static translators :-) > > > > > It somehow appears to me at the moment that the usage of two virtual > > nodes mirroring the real node with and without translators might be a > > guaranteed solution, even if such a standard RPC does not exist. In > > this case '-gunzip' will just choose the untranslated mirror, won't > > it? > > Well, yes. As explained above, "-gunzip" could always ask for the > untranslated node by means of a special interface provided by the main > proxy. 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... :-( scolobb
