Subject | SuperServer vs. Classic |
---|---|
Author | Jim Starkey |
Post date | 2000-05-30T14:20:21Z |
At 12:44 PM 5/28/00 +1000, Jan Mikkelsen wrote:
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
>This is the single most difficult and important question facing future
>All this applies to superserver, of course. Classic should just be taken
>into the woods and shot.
>
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