Re: [TCLUG:12613] Reasons not to use Apache?

["Eric M. Hopper" <hopper@omnifarious.mn.org>]

On Thu, Jan 20, 2000 at 02:42:20PM -0600, Dave Sherohman wrote:
> 
> The server in question will be the back end for the system management
> client application.  The tables it updates will control the operation
> of (existing) telephony software.  Specifically, it will be used to
> create and maintain call trees and manage hardware configuration for
> the machines that do the actual work.
> 
> It will be replacing (at least) two existing programs, both of which
> currently accomplish this by directly accessing the relevant tables
> (which may be on a machine physically located halfway across the US).
> The primary objectives are to simplify setting up the telephony
> servers and eliminate the need to have user accounts on all the
> servers you're managing.  (The existing system is very ad hoc and only
> set up for internal users, so lots of manual editing of tables is
> required as well as going through the management programs.)

	It sounds like what you want is the second tier of a three-tier
client server system.  Having a seperate process for this is the right
thing to do IMHO.  In all likelihood, the manipulations performed on the
data are somewhat complex, and subject to a whole bunch of rules about
what constitutes good or bad manipulations.

	Managing that whole process over HTTP is a HUGE pain, and
wouldn't work well at all.

	If my StreamModule system were more mature, and the Common Data
Language (preprocessor?  compiler?) were written, I'd recommend my
StreamModule system.  As it is, I recommend (as much as I dislike it)
CORBA.

	If you had a surefire way to do session tracking over HTTP, it
would be a different matter, but you really don't.  Cookies don't really
solve the problem.

>> You'd have to prove that to me. Can you post your docs?
> 
> 'Fraid not.  Basic reasoning is that many of the things in the
> hierarchy are password-protected and I'm not into sending passwords
> across the net for every action the user takes.  The user should
> also be able to request locks on things, which can be problematic if
> they're able to disappear without notifying the server.

	There's one excellent reason for you.  Transactions are hard to
manage over HTTP, which is essentially connectionless.

>> Minimizing discrete server processes is a practical matter, if you ask me.
> 
> Even when it's a matter of 1 heavyweight server vs. 2 collectively
> smaller ones?

	Minimizing server processes is pointless under UNIX.  The real
problem would be if the two processes engaged in a lot of heavy
request/response style communication that required a context switch for
every message.

Have fun (if at all possible),
-- 
Its name is Public Opinion.  It is held in reverence. It settles everything.
Some think it is the voice of God.  Loyalty to petrified opinion never yet
broke a chain or freed a human soul.     ---Mark Twain
-- Eric Hopper (hopper@omnifarious.mn.org  http://omnifarious.mn.org/~hopper) --

PGP signature