Sean,

I couldn't agree more. The 90+% need to be taken care of. For our
situation, thread-safe SMP on NT is the highest priority. That is
something I will continuely bring to the attention of the InterBase
development community. It is unfortunate, that InterBase doesn't
perform as strongly with the latest upgrades. In theory I believe
SuperServer is better, I would just like to see it be so in performance.

Sean Stromberg

-----Original Message-----
From: Leyne, Sean [mailto:InterbaseArchitecture@...]
Sent: Tuesday, May 30, 2000 10:22 AM
To: 'IB-Architect@egroups.com'
Subject: RE: [IB-Architect] SuperServer vs. Classic


Dalton,

I don't agree.

Support for thread management across servers ("beowolf type constructs")
should NOT have any impact on the dropping Classic decision.

Let's get IB running on server equipment and solving problems which
exist in 90+% of the existing environments. The "beowolf" situation you
describe falls well outside of this range, I would expect applies to
less than 0.5% of cases (something like support for SCO).

Finally, IB can't (and shouldn't) be all things to all
people/users/developers. I have detected a tone running through a
number of the postings lately which have tended to suggest otherwise.


Sean
-----Original Message-----
From: Dalton Calford [mailto:dcalford@...]
Sent: Tuesday, May 30, 2000 11:31 AM
To: IB-Architect@egroups.com
Subject: Re: [IB-Architect] SuperServer vs. Classic

I personally would not want to see the classic version dropped until
supersever supports threads that work across processors (and by
extension accross machines in beowolf type constructs).

best regards

Dalton

Jim Starkey wrote:

>
> At 12:44 PM 5/28/00 +1000, Jan Mikkelsen wrote:
> >
> >All this applies to superserver, of course. Classic should just be

taken

> >into the woods and shot.
> >
>
> This is the single most difficult and important question facing future
> development. Among the issues:
>
> 1. SuperServer only works on threaded platforms.
> 2. Security is hopeless in Classic
> 3. The conditionalization of the code makes ongoing maintenance
> of two branches highly problematic.
> 4. Support both on the same machine borders on impossible
> 5. Given an abstract workload, neither is a clear winner.
> Given a specific workload, one will generally outshine
> the other.
> 6. Asking the using at installation time which to install
> time is problematic -- how could a new use possible make
> an intelligent decision.
>
> An argument can me made -- but I haven't convinced Charlie -- that
> removing Classic will speed up SuperServer (algorithms are now chosen
> that work well in both), and that speeding up SuperService is

necessary

> to kill off Classic. Chicken, egg.
>
> Thoughts?
>
> Jim Starkey
>
>

------------------------------------------------------------------------

> Failed tests, classes skipped, forgotten locker combinations.
> Remember the good 'ol days
> http://click.egroups.com/1/4053/4/_/830676/_/959696797/
>

------------------------------------------------------------------------

>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com

------------------------------------------------------------------------
Best friends, most artistic, class clown Find 'em here:
http://click.egroups.com/1/4054/4/_/830676/_/959700578/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com



------------------------------------------------------------------------
Find long lost high school friends:
http://click.egroups.com/1/4056/4/_/830676/_/959703833/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com