> On 13/11/03 22:24 -0800, Andrew Hurst wrote: >> >> The only problem I see with it is the CURRENT codebase quickly dropping >> the old code that has made developing for Scoop that much harder, and >> replacing it with spiffy clean new stuff. Then new features getting >> added >> that rely on the new whizbang code. > > I think "quickly" might not have necessarily been the right word. Or > maybe it will. That would be kinda nice. It probably was the wrong word. It still is maintenance programming, any way you cut it. Which isn't exactly the most inspiring of tasks... > ... > The former would be ideal, of course. As far as boxes that rely on > internal functions, my idea would be to either keep the same function > names and arg lists for the rewritten code, or maybe add a Scoop 1.0 > compatibility layer for old boxes. That way, we might hope to keep old > boxes around and make the transition a little less painful. > > How's that sound? I think both are mainly the same thing. And I also think that would probably be the best way to go about it. Somehow figure out what functions get called from boxes, and leave them around. Take the options, and call the new functions to perform the same function. Shouldn't be too hard, but depending on how Scoop was modified (i.e. to be more OO) it could be a big performance hit. Sounds like a good time. -Andrew