httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: HTTP + XML + SCP = HTTP/ng
Date Fri, 11 Feb 2000 00:17:07 GMT
bleh, i'm on neither,, nor so if folks want those other folks
still in on this thread then could someone please forward?  thanks.


On Thu, 10 Feb 2000, Dean Gaudet wrote:

> On Mon, 7 Feb 2000, Martin Pool wrote:
> > Given the state of Java and HTTP today I wonder whether it would be
> > better to build a toolkit of Java classes for building HTTP servers,
> > rather than using AJP to plug into Apache.
> that's what i was advocating.
> > Where's Apache going to go in the future?  Is it going to be a single
> > big do-everything program, or a cluster of complementary projects?  
> i hope not, but unfortunately there's a little bit of momentum... i've
> made a couple attempts to suggest ways we could split it up.  but i don't
> have the energy to evangelise the topic.
> so one of the points i brought up earlier in the thread hasn't been
> addressed:  what problems are people trying to solve?
> the web applications of which i'm aware are essentially composed of:
> - static content
> - dynamic content which is cacheable (i.e. almost static)
> - dynamic content which is uncacheable
> the best url design includes all these components under the same hostname.  
> so either all the services end up on one box, or some sort of front-end is
> required.
> both apache and squid perform as front-ends today.
> if we had a front-end server with the following feature set:
> - full HTTP/1.1 proxy cache
> - HTTP/1.1 server capable of serving static files
> - uses async i/o at least for serving static files (which includes
>   files in the proxy cache)
> - capable of dividing the urlspace amongst different pools of
>   backend servers
> - capable of load balancing amongst several backends within a pool
> - handles persistant/pipelined connections with clients and with
>   backends
> - SSL
> in this scenario i would expect the back-ends to talk http.  the front-end
> would parse the incoming request and either handle it from disk/cache, or
> pass it through to a back-end.
> then i'd really like to know what applications can't be solved?  real
> world examples please, you know how much of a pain i am :)
> i mean i can think of some.  consider authentication.  you might want your
> entire urlspace to live behind an auth method which you want to implement
> in java to talk to your databases in some way.  but you've got portions of
> your urlspace served by static files, some served by perl, and some served
> by java.
> well, the front-end could make a SOAP request (XML over HTTP) to your java
> back-end, and presumably your java back-end can return a response which is
> temporarily cacheable.  the front-end keeps that in its proxy cache...  
> (or heck it could just proxy a HEAD request... my point is that it can
> just pass the entire client request to the backend.)
> anyhow we could go through each phase of the current module API and come
> up with an application... but when i sit down and think about these things
> i frequently find myself showing that a particular api phase just isn't
> needed.
> aren't the php and java back-ends just content handlers today?  they don't
> even touch other API phases right?
> i honestly don't see the point of CORBA, or any of the other binary
> protocols.
> - they require more code, which clobbers L1 cache efficiency (which i'm
> willing to bet will eliminate any perceived benefit you're hoping for by
> making things binary)
> - they require us to document the interfaces and be careful about defining
> semantics... whereas HTTP/1.1 proxying is well defined by rfc2616, that
> work is done for us already.
> - some of us haven't had the patience to keep up with the object protocol
> acronym soup of the day ;)
> - most of us will end up using XML anyhow, and we've already got XML
> libraries in our codebases (this is if we even need SOAP)
> - code reuse #1
> about the only extension to HTTP which i think we might want to consider
> is Simon Spero's SCP -- session control protocol.  (you can find a version
> of it named TMP used without credit in rfc2371).  SCP allows you to
> optimise front-end/back-end communications by multiplexing multiple
> streams into one tcp session... big performance boost from this.
> HTTP + XML + SCP = HTTP/ng :)
> other than C and java libraries implementing SCP, what's missing?
> Dean

View raw message