Hi, On Thu, Sep 25, 2008 at 11:49:48PM +0300, Sergiu Ivanov wrote: > On Sat, Sep 20, 2008 at 2:04 PM, <[EMAIL PROTECTED]> wrote: > > On Thu, Sep 18, 2008 at 10:34:22PM +0300, Sergiu Ivanov wrote: > > > On Fri, Sep 12, 2008 at 7:37 PM, <[EMAIL PROTECTED]> 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-
