John Bellardo wrote:

>Hi,
>
>>[..big snip..]
>>
>>
>
>It seems to me we need to (more or less) decide on the target
>architecture before we can make intelligent decisions on how to make it
>happen. For example, if our final goal is really just a "better" SS,
>then it may well be foolish to ignore all the work that has already
>gone in to making SS what it is. But in the same vein if our goal is a
>multi-processes model it may well be foolish to ignore all the work
>that has gone in to classic.
>
>

We don't need (or want) two architecture, but from the bit I saw, I
wasn't too impressed with the current SS approach to threading (no
offence meant, and I appreciate that it got done at all).

I think that as I feel, porting classic to run as threads and picking up
the bits of super worth keeping along the way will give us the best
outcome in the end.

I also think it' s important for us to continue to provide an embedded
solution, many people want to install a local db that has zero impact or
visibility with their small app, and that app could be on a palm pilot
... in addition to looking at the server solutions.

But from a previous discussion with John, both the embedded and server
solutions want to share most of the code, and provided different
implementations of subsystems where required. (Certainly the current
#ifdef approach needs to change).

But one of the "joy's" of opensource, is that people will work on what
is of interest to them, and what they think is the "best" solution. So
in the short term (which at our change rate that probably means about 3
years) I'd see ideas being worked on in both classic and super, that the
changes made will probably benefit both models, and that after 3 years
we'll only have one model left.

Mind you Im not sure what a palm pilot will look like in 2005 :-).

Cheers

Mark