Re: Namespace-based translator selection; project details

[olafBuddenhagen]

Hi,

On Wed, Jun 18, 2008 at 08:15:10PM +0300, Sergiu Ivanov wrote:
> 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:

> > 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?

Hm... I don't remember, whether translators always have to implement all
the callbacks from libtrivfs/libnetfs/libdiskfs, or whether some of them
are optional?...

In the latter case, additional RPCs probably could be introduced without
modifying the actualy translators.

But you are right that creating a new interface most likely is easier --
I just wonder whether extending the existing one wouldn't be more
elegant...

But I think we can safely postpone this questions, as we aren't even
sure yet whether new interfaces are needed at all :-)

> 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?

I have doubts about this being the best place. Probably better to look
at the helper libraries (trivs/netfs/diskfs), and/or the MiG-generated
server side stubs.

> > > 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.

Well, it was clear that you did understand the underlying file system
doesn't change. But before my latest protest, you still didn't have
understood that accessing a node through special syntax doesn't have
*any* side effects at all... :-)

> 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?

Exactly.

> 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)

Indeed :-) I'm glad we got that sorted out.

-antrik-