[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: [zzdev] Re: ***ATTENTION***



> 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?)

Using the MultiplexingMediaserver to manage multiple pools was unfinished
functionality and AJ didn't apparently have time to finish it or to
write tests before he left.

> > > 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 :) )

I'll take any solution that works right now. The mediaserver is pretty
well encapsulated so the added complexity of copied code doesn't matter
that much.

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

Sounds good. Who will code this?

	Tuomas