Hi,
On Wed, Jun 11, 2008 at 09:01:27PM +0300, Sergiu Ivanov wrote:
> On Tue, Jun 10, 2008 at 10:19 PM, <[EMAIL PROTECTED]> 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.
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...
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.
> 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.
> > 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.
> 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.
> 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 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?...
-antrik-
