Jim Starkey wrote:

> If classic becomes SMP friendly -- thread safe with a multi-threaded
> client -- is there any reason to continue differentiation of the classic
> and superserver engines?

Also as classic starts using shared memory to hold common data structures.


Jim Starkey wrote:

> I am not suggesting that we kill the superserver architecture, per se,
> but we merge classic and superserver into a single unified engine.

...

> If we can flush the difference between classic and superserver,
> everyone's life gets a great deal simpler.

Yes, I agree it's not a killing but a merging, of superserver and
classic server architecture taking (hopefully) the best of both, and
abstracting out some of the runtime differences (threads/processes
allocation to shared memory/normal memory for instance). I see this as
very beneficial.

However, in addition to "super server" and "classic server" we also have
the original classic direct connect model (or "embedded" mode as I've
termed it).

I know that many think that we only need a firebird server version, but
in building embedded solutions the direct connect model has some
advantages.

I would hope, and think it's reasonable, that a smart way can be found
in the merge of the two server architectures to preserve the original
embedded architecture as an option.

Quite likely, since locking, interprocess communication, and security
operation differs so much in embedded mode to (both) the server modes,
that to aid the merge of the servers, the embedded mode may need to
loose it's multiclient ability, thus restricting db access with embedded
to one client at a time. That is still likely to be suitable for a
desktop app or a palm pilot program storing a bit of data.




Jim Starkey wrote:

>
> What am I missing?
>

And Arno replied:

> Time :-)

Jim I think your lucky, (and we're also lucky) that you have some time,
especially paid time, but keep it in mind, as you find crap etc in your
travels, that having time, or paid time, is not a luxury many here have.

We're all after the best code/system, and I personally prefer you care
enough about the code, do the "Grrr" thing even when it's occcasionally
misdirected.

(I know for my part, the unix/linux makefiles although better than the
original, are certainly not what I'd like them to be, I'll wait my turn
for you to drift into them and for me to be found out :-).


Cheers

Mark