[PHP-DEV] Re: [Proposal] "Relayed" Apache API Project (fwd) From: rasmus <email protected>
Date: 01/30/00

---------- Forwarded message ----------
Date: Sun, 30 Jan 2000 06:50:20 -0800 (PST)
From: Dean Gaudet <dean <email protected>>
To: Ben Laurie <ben <email protected>>
Cc: Stefano Mazzocchi <stefano <email protected>>,
     Apache Committers <committers <email protected>>,
     Simon Spero <ses <email protected>>
Subject: Re: [Proposal] "Relayed" Apache API Project

On Sun, 30 Jan 2000, Ben Laurie wrote:

> That assumes that the only interesting stuff in Apache can be captured
> in a two-message HTTP session. I question that assumption. Besides,
> mod_proxy already provides this facility.

i know... but that's because the main uses i know of this type of split
are dynamic content engines... which sometimes generate static cacheable
content -- apache would handle the static stuff, and passes through the
dynamic stuff (with caching, load balancing, failover, session
affinity...) if folks could present us with other common use-cases it
would help.

you're choosing a transport/data-representation layer for RPC -- from my
point of view the primary difference between, say SOAP (XML/HTTP) and
CORBA is that CORBA is a binary protocol. using CORBA requires extra
libraries which you aren't necessarily already using. using SOAP would
reuse libraries that are already used for building HTTP applications.

some time ago the performance freak in me relaxed and started ignoring the
inefficiencies in text protocols such as SOAP... because the
inefficiencies are recovered in other ways -- such as better
maintainability.

it means i'm advocating putting an HTTP server into dynamic engines like
jserv. but it doesn't have to be a full fledged HTTP server. or maybe it
can be full fledged -- with apache 2.0, someone could write a jserv MPM
which runs in java threads and uses native callouts to apache.

what if we rearranged apache's code base so that we built a (shared)
library called libhttp, which takes an abstract socket (iol), and a set of
hook methods (the "module API"). then applications such as php, perl and
jserv would link against this library and be http-servers unto themselves.

the change here is that instead of building an executable as the primary
target of apache, we build a library. i think this simplifies a bunch of
things -- folks right now go through gyrations to build a combined
php/perl apache. instead they could build three separate executables
linking the same library and using SOAP to communicate.

there's a bunch of things which this approach makes easier -- for example,
threaded apache has difficulty spawning CGIs because fork is expensive so
you need to put that in another process. that other process could be an
unthreaded apache, rather than what we have now with mod_cgid which is
another example of a "relay" protocol.

obviously i'm skimping on lots of details. but this is an interesting
direction isn't it?

Dean 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>