Hello,
On Mon, Jun 16, 2008 at 6:13 PM, <[EMAIL PROTECTED]> 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.
scolobb
