On Sat, Jun 7, 2008 at 3:13 PM, <olafBuddenhagen@gmx.net
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
That's clear, the nodes will be created when required.
> It seems to me that no actual classification of translators intoThe bit you are overlooking is that a translator is attached to a single
> 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
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,
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. IWell, this is really orthogonal. Of course one could use Flavio's Lisp
> 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)
bindings to write "-u" for example -- just like for writing any other
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 properThe communication channel is established the moment a translator is
> communication channel between the main proxy and the special
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
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?Now it's getting really confusing... Maybe we should start drawing
> 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?
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
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
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
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
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... :-(