Re: ***ATTENTION***

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Hi Tuukka!

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
of coding.

(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
> first.

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
somewhere else.

- Benja