On Mon, Jun 16, 2008 at 6:13 PM, <
olafBuddenhagen@gmx.net> wrote:
On Wed, Jun 11, 2008 at 09:01:27PM +0300, Sergiu Ivanov wrote:
> Frankly speaking, I still have no idea as to the communication between
> the proxy and the translators it loads. I suppose the proxy will have
> to exhibit an interface in a .defs file, but I know very little about
> such things yet.
Yes, that's pretty much it. The core functionality of the proxy -- it
being a filesystem proxy -- is implementing the FS interface (fs.defs),
on the virtual nodes mirroring the underlying filesystem. Most of the
requests on this interface are simply forwarded to the underlying real
nodes; but some are handled specially: Most notably the name resolution,
which parses the special ",," suffixes, and invokes the corresponding
translators.
Aha, I had similar suppositions.
If it turns out that the standard interfaces are not sufficient to
obtain the untranslated node and the translators attached to it
seperately, this means we need to add some special RPC(s) for that,
which would be handled by the proxy, but probably not by other servers.
These could be put in a completely separate interface for translator
control. But it might be easier just to add them to the existing fs.defs
-- after all, this is closely related to some of the functionality
fs.defs already provides...
Doesn't fs.defs describe the interface common to all translators, which
implement a filesystem interface? In this case, won't altering this file
bring about problems because of the fact that the existing FS translators
will not comply with the new interface definition?
Note that translators attached to a file system (the proxy in our case)
are basically just a special kind of client. They implicitely get a port
to the node they are attached to, while "normal" clients obtain such
ports through name lookup. The translator can invoke RPCs on this port,
using the FS interface, just like any other client.
OK, the general idea is now clear. Will it be right if I try to read the code
of something like ext2fs in order to understand how to exhibit an
interface complying with fs.defs?
> Do you mean that, after a filter translator has used the virtual node
> mirroring the untranslated version of 'file', this virtual node should
> go away? I thought it should stay for a longer time, so that it won't
> be required to retrieve it anew when another filter translator is
> loaded.
Well, whether caching is applied, is really just an implementation
detail. I wouldn't bother with caching for now.
OK, that's clear.
> > 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.
> >
> Suppose the client accesses 'fie,-u'. The proxy will create the three
> nodes you have named above and the client will receive the node 'file'
> translated by 'x' only.
Yes.
Note that the three nodes are not created immediately. Rather, the node
with all translators is created first, and "-u" attached to that. "-u"
then requests the untranslated node, and finally "-u" requests the one
with "x" only, which is returned to the client.
Yes, this process looks rather clear to me now. Thank you!
> What shall the proxy return when the client asks for 'file' simply?
> The node with translator 'x' only, or the node with all translators
> ('x', 'u', 'y', and 'z')? I'd feel it natural if the proxy would
> return the node with translator 'x' only
I'm not sure what you mean here exactly. If you mean the client starting
a new lookup, this time for "file" only rather than "file,,-u", then NO!
I fear the initial misundestanding still hasn't been resolved
completely. The nodes never permanently change simply because they were
accessed with a special suffix earlier! Each new lookup starts from the
underlying filesystem, and applies only exactly what is requested by the
special syntax of *this* request.
No-no! I'm not talking about changing the underlying filesystem. It seemed to me
that after applying '-u' the proxy should forget about the static translators
actually present on the node in the underlying filesystem. In other words, I
thought that after applying the filtering translator '-u', subsequent requests
for 'file' should yield 'file' with translator 'x' only. As far as I can understand
now, if the user wants to access simply 'file' after applying '-u', they will
always get the node 'file' with translators 'x', 'u', 'y', and 'z' -- all the static
translators present in the underlying filesystem, right?
> and then it somehow seems to me that we could dispose of the version
> with all translators,
Well, if we don't cache anything, I think the version with all
translators is only created temporarily indeed: It is the node the
filter translator is attached to. And, unless I'm missing something, the
filter is only needed once, when performing the inital lookup. It then
returns a port to the filtered node ("file" with "x" in our example);
the client will then do further actions on this node. The filter itself
is not used anymore; it could terminate immediately and thus free the
node it was attached to.
So, requests for 'file,,-u' will always yield the same result, won't they?
(I'm asking this to make sure I understand everything correctly)
> so that there would remain only two nodes: the one with 'x' attached
> and the completely untranslated node, used temporarily by the filter.
I don't understand. Why would the temporary untranslated node remain?...
No, it won't remain, of course. I misused the word 'remain' here. As you said,
the untranslated node will be created temporarily and will go away when not
required any more.