httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [Proposal] "Relayed" Apache API Project
Date Sun, 30 Jan 2000 15:00:59 GMT
Guys, could we please move this discussion to new-httpd.  This is
obviously something that is interesting to a whole bunch of people
including the PHP project, of course.

On Sun, 30 Jan 2000, Dean Gaudet wrote:

> 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

View raw message