Hello, <olafbuddenha...@gmx.net> writes: > On Fri, Apr 10, 2009 at 08:51:03PM +0300, Sergiu Ivanov wrote: >> <olafbuddenha...@gmx.net> writes: >> > On Wed, Apr 08, 2009 at 08:17:30PM +0300, Sergiu Ivanov wrote: > >> >> You see, I suppose that some time later we will be adding some >> >> specific merging rules, which would be very difficult (if not >> >> impossible) with the approach you are suggesting (about reusing >> >> unionfs as a whole). >> > >> > On the contrary -- having the merging functionality in a separate >> > component, would make it easier to replace it... >> >> Completely agreed, but if this separate component is unionfs, we will >> anyway have to fork off its code base. > > Not at all -- the idea is to use something completely different instead > of unionfs, if we require different functionality... > > Having the merging code in a separate component (be it unionfs or > something more specialized), would indeed make it easier to use > different policies. However, the complexity involved makes me object to > such an approach, at least in the initial implementation.
This was the thing that made me a better adept of the forking idea. > Note that at the beginning of the namespace based translator selection > project, I suggested handling various special syntax in external > components (like the filter), instead of hard-coding it in nsmux, to > gain more flexibility. I believed it would simplify the design, because > this way we wouldn't have to think about the various policies when > working on nsmux itself. I wasn't aware how much the added complexity of > the modular approach will make it harder to figure out the basics; how > much it will frustrate progress... Yes, I remember our discussion on that matter... > We are in a very similar situation here -- but I have learned from last > time. Go for the simple approach first, and only later think about a > more flexible solution. We have a deadline to meet. OK. I think I've got the idea :-) >> >> Moreover, some translators (like unionfs and hence unionmount) >> >> would like to keep a list of nodes they own and drop nodes when >> >> they don't need them. This policy would require more effort if a >> >> shadow-node server is involved. >> > >> > Why? >> >> I am mainly concerned with the fact that dropping the node will >> require accessing the shadow-node server (if I understand things >> correctly), and invoking an RPC is always more effort than just >> cleaning up a local piece of memory. > > Ah, I wasn't aware that you were talking about monolitic implementation > vs. external implementation of internal nodes here... In that case, I > totally agree. > > I thought you referred to individual processes for each internal node > vs. a central server for them -- which, as I said elsewhere, doesn't > make much of a difference I believe. I see... I cannot see why it should make difference, either. Regards, scolobb
