Re: A New Design of nsmux (discussed on IRC on 2008/09/07)

[olafBuddenhagen]

Hi,

On Thu, Sep 25, 2008 at 11:49:48PM +0300, Sergiu Ivanov wrote:
> On Sat, Sep 20, 2008 at 2:04 PM, <olafBuddenhagen@gmx.net> wrote:
> > On Thu, Sep 18, 2008 at 10:34:22PM +0300, Sergiu Ivanov wrote:
> > > On Fri, Sep 12, 2008 at 7:37 PM, <olafBuddenhagen@gmx.net> wrote:

> > It might be possible though to find some smart way to factor the
> > functionality, so that recursion would be handled naturally by the
> > interaction between the translators, without need for any explicit
> > support in any of them. I don't think this would really mean a
> > simplification in the sum of code involved, but it might make things
> > simpler *conceptually*, which could still be a worthwhile goal...
> 
> Sounds rather tempting :-) It would be great if we had managed once to
> bring things to such a wonderful conceptual level. Probably, further
> development of the current implementation of nsmux can provide us with
> some ideas.

Yeah, that's what I am thinking as well: This stuff seems too complex to
figure it out on a purely abstract level; only with an actual
implementation at hand we can hope to get a better understanding...

> > > > I wonder thus whether it wouldn't be advisable to share dynamic
> > > > translators resulting from equivalent lookups. But this would
> > > > again pose problems with badly designed translators, that behave
> > > > differently with a single instance shared between clients than
> > > > individual instances for each client...
> > >
> > > I've been thinking about this problem for about a month already,
> > > and my opinion is that we should share dynamic translators. I
> > > wonder whether it is nsmux's responsibility to care about badly
> > > designed translators. If dynamic translators would not be shared,
> > > it could indeed result in considerable overheads, and the worst
> > > thing is that these expenses would appear in the cases of
> > > well-designed translators, too.
> >
> > Well, the point is that it would complicate nsmux -- implementing a
> > specific solution to a generic problem...
> >
> > I tend to think that we should just ignore this issue here; and only
> > when it actually poses serious problems in practice (as I'm sure it
> > will sooner or later, either with nsmux or in some other situation),
> > it should be addressed by an independent project, at the framework
> > level.
> 
> OK, we can easily forget about this problem for now, especially since
> it really does not create really serious problems right away. However,
> I am inclined to think that sharing dynamic translators should be
> implemented some time, because I like when resources that can be
> shared are shared :-) Or are there some considerations that could show
> that this idea is somehow malefic?

Well, I'm not sure what you mean exactly now: Sharing dynamic
translators in nsmux, or a generic translator reuse solution?...

If it's the former, I already stated the problems. For one, the code
would be in the wrong place: it is a generic problem, that should be
solved in the translator framework itself, not by some ad-hoc approach
in nsmux.

The other concern is that the behaviour of translators is not really
specified, and thus it's totally possible that some translators would
behave differently when shared -- I called these "badly behaved" above,
but there is really nothing that prohibits such behaviour... So it could
result in inconsistencies; and thus -- as inconsistent behaviour
generally tends to do -- in possible usability and even security issues.

Doing it in the translator framework should help with the latter
problem, as this way are in a position to activate reuse only on
explicit request by the translator, and thus can be sure that it will
only be done for translators that are "safe".

> > Well, we arrived at the conclusion that most dynamic translators
> > will probably become useless when the underlying filesystem goes
> > away, as there is probably little point in using magic name lookups
> > to start translators not using the underlying node...
> >
> > Yet, I don't see why we should explicitely kill them. I think they
> > should just deal with the underlying node going away, just as they
> > would have to deal with it when sitting on some other filesystem.
> 
> Hm, that's right. I've never looked at this question from this point
> of view...

Consistency is always a good guide: Not only does it generally point to
the most correct solution, but often enough also the simplest one :-)

> > In my case, I tend to start thinking about such stuff at all
> > possible moments, often when I'm supposed to be doing something
> > completely different. The result being that I get nothing done,
> > because I spend most of my time thinking about stuff I will never be
> > able to implement anyways, as I get nothing done... [sigh]
> 
> Instead, you always have a lot of new and interesting ideas :-) People
> generally tend to remain in the shelter of something already
> well-known, and new and interesting ideas are rare.

Well, I do flatter myself that I have more original ideas than the
majority of people :-) But what's the use, if most of them will never
get implemented?...

> Probably, there have to be some other people to implement your ideas,
> while you will be designing something new and fancy.

Unfortunately that's not how it works in general: people want to work on
their own ideas, not on other people's ones... I can't just hope that
someone else will implement my ideas -- either I do it myself, or nobody
will. (GSoC is a bit of an exception here.)

If nothing else, others can't work on my ideas without knowing them --
and I'm very poor at presenting my ideas in a convincing manner :-( In
fact I have a hard time even writing them down at all... I started my
blog in the hope that it will allow me to share some of my ideas without
too much effort, but it turned out that even for a blog entry I often
need two days or so.

> The problem is that I want to maintain my grades at a relatively high
> level, because this is likely to influence my attractiveness for my
> potential employers :-) I would like to work in Open Source only, but
> I am not sure this will provide me with sufficient monetary resources.

Well, nowadays there is a considerable number of jobs in free software
development. However, such companies usually look for people who already
gained a reputation as free software developers.

So if you seriously hope to get such a job, you probably can't get away
without getting involved in some popular free software project ASAP...

-antrik-