[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: ***ATTENTION***
- To: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Re: ***ATTENTION***
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Fri, 8 Feb 2002 09:32:24 +0200
- Cc: ZZ Development <zzdev@xxxxxxxxxx>
- In-reply-to: <3C62A5FA.63C43F8D@xxxxxx>
- Mail-followup-to: Tuomas Lukka <lukka@xxxxxxxxxxxxxxxx>, "B. Fallenstein" <b.fallenstein@xxxxxx>, ZZ Development <zzdev@xxxxxxxxxx>
- References: <Pine.LNX.4.44.0202071301280.12315-100000@xxxxxxxxxxxxxxx> <3C62A5FA.63C43F8D@xxxxxx>
> 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
> > 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?