[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: ZZ Development <zzdev@xxxxxxxxxx>
- Subject: Re: ***ATTENTION***
- From: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Date: Thu, 07 Feb 2002 17:06:18 +0100
- References: <Pine.LNX.4.44.0202071301280.12315-100000@xxxxxxxxxxxxxxx>
Tuukka Hastrup wrote:
> Sorry, I didn't realize MultiplexingMediaserver was in use somewhere
> because it didn't work. Now I see we could because the problem was only
> with pointers.
And I didn't realize it didn't work, because the tests worked fine. ;-)
(Why did they, by the way? Shouldn't something in impl/test have messed up?)
> > I don't understand. Why duplicate code into a hack instead of doing it
> > correctly (lift MultiplexingMediaserver to the next level: give it
> > intelligence about which pools it may save into and which it may not)?
> We have had the CVS version too long in unusable state - for everyone
> except our research group. It is a hack but doing it the right way takes
> some time and can easily be done later.
Does this mean the problem is the effort to do it right, and not that
you think copying the code is better/the only way (as Tuomas seemed to
indicate)? If so, why not let me do it? I estimate about 10-15 minutes
(That's much less work than maintaining two versions of the same thing
for a long time, methinks :) )
> > The point of MultiplexingMediaserver
> > is to solve a general problem instead of solving the same problem over
> > and over again (when it was written, the problem at hand was that the
> > tests needed a transient mediaserver, but it's also been used for
> > public/private pool separation, to use the public HTTP repository for
> > loading the space but saving to a local disk, etc.).
> At the moment I see it being used in TestImpl, Client and NileDocument.
> For the Client it works to the extent I've tested it. For TestImpl the
> hack works. How should it work in NileDocument?
NileDocument is legacy anyway. I'll remove it.
> When we are to do multiplexing the right way, we should have it specified
My point is not to have an all-inclusive spec, but to extend the spec
each time we have a new need the old spec does not satisfy (as opposed
to: writing a new class with a different spec every time). The spec up
to the present point was very simple: save only into the first pool. I
think the next step would be as I said: three parameters in the
constructor: read-write pools; read-only pools; and the fallback pool
(which is read/write too) in which we save everything we cannot save