Re: [Proposal] "Relayed" Apache API Project (fwd)

---------- Forwarded message ---------- Date: Sun, 30 Jan 2000 06:50:20 -0800 (PST) From: Dean Gaudet <dean@apache.org> To: Ben Laurie <ben@algroup.co.uk> Cc: Stefano Mazzocchi <stefano@apache.org>, Apache Committers <committers@apache.org>, Simon Spero <ses@tipper.oit.unc.edu> 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