Re: Namespace-based translator selection; project details

[olafBuddenhagen]

Hi,

On Tue, May 27, 2008 at 07:23:49PM +0300, Sergiu Ivanov wrote:
> On Mon, May 26, 2008 at 8:49 PM, <olafBuddenhagen@gmx.net> wrote:

> By the way, which would be the average size of a translator stack in
> your opinion? I don't think my assessment of the situation is really
> well-founded, by I suppose that there won't be really much
> translators.

Well, presently we actually use quite few translators; but this is
something I want to change -- and the namespace based translator
selection is part of the plan :-)

So, while presently pretty much all translators are "single", this might
change a bit once translators are used the ways I envision. It's hard to
tell whether it will be result in a lot of translator stacking, though.

> > As for the implementation, we would have a translator named
> > "-gunzip", which would again proxy the underlying directory tree,
> > but ignoring any gunzip translators present.
> >
> > Of course, we do not want to implement the "-" variant of each
> > translator explicitely. Rather, we can just make them all links to a
> > generic filter translator, which always skips the translators
> > matching the invocation name (without the "-" of course), i.e. if
> > invoked as -gunzip it would skip any gunzip translators, as -mboxfs
> > any mboxfs translators etc. [...] Also, many of the shorthand
> > translators can in fact simply be links to the normal forms, e.g.
> > "x" for xmlfs. Only the magic ones like "u" need a more explicit
> > implementation.
> >
> > That's the beauty of this approach: We only use standard mechanisms,
> > and thus can implement the individual shorthands whatever way we
> > want :-)
> >
> 
> As far as I can understand, there won't be a file with a dictionary of
> shorthand translator names (like I suggested in the first message),
> instead there will be links with shorthand names, pointing to the
> required translator; do I get it right?

That was my idea, yes.

> However, the matter about ignoring some translators ('-u', for
> instance) is a bit foggy for me. Do you mean that these should also be
> symbolic links?

That would be one of the implementation methods I suggested: Links to a
common filter translator. The script variant might be more elegant,
though...

> I thought, it would be the job of the proxy filesystem to parse the
> '-' before the names of translators...

That's what I thought as well, up until the moment when I came up with
the modularization idea while writing the last mail :-)

The more I think about it, the more I like the idea. It really
simplifies the individual components, at the same time giving sheer
endless flexibility as to what special syntax we want to implement, and
how...

Of course, it is still possible to implement some hard-coded mechanism
in the main proxy later on, if it turns out too inefficient otherwise.

> And if not, when we stack a '-gunzip' translator upon a 'gunzip'
> translator, don't we get into redundancy somehow?

I don't see any redundancy...

The example shows a real problem though: For "-gunzip" applied this way
to take any effect, the "-gunzip" translator must be executed *before*
opening the underlying node -- before any static translators that might
be present on the node get traversed. When applying a "normal"
translator like gunzip on the other hand, it should be simply be stacked
on top of anything that might already be present, just like stacking
static translators. Not sure about the best behaviour when applying a
magic translator like "u" or "-u" recursively -- in this case, I'm not
sure it's necessary to apply it before opening the node; but on the
other hand it shouldn't hurt to do so...

In any case, it seems necessary to establish some rule when translators
should be stacked on top of static ones, and when they should be
executed before accessing the node. This is unfortunate, as it requires
some policy in the main proxy after all...

> By the way, it seems to me that if it would be possible to ignore only
> the whole stack of translators, this problem will dissolve.

I don't see how this changes anything here?

> Just a few hours ago such a question occurred to me: should the proxy
> filesystem pay attention to the translators that had been set
> explicitly (via settrans) before the proxy was loaded? I mean, should
> they be included in the translator stack?

Yes of course -- that's what I've been referring to as "static
translators"!

I wonder now, what did you think I meant by "static translators", if not
that?...

> Maybe, at startup, the proxy filesystem will go through all files in
> the directory it is set upon, and, for each entry, remove the
> translators found and include these translators in the translator
> stack within the proxy.

Again, "remove" is a rather ambiguous term in this context; I'm not
quite sure what you mean here -- I hope you don't think of actually
removing them from the underlying filesystem?...

Actually, I don't understand at all what you are getting at in this
paragraph :-(

-antrik-