httpd-dev mailing list archives

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

Dean

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
> 
> 


Mime
View raw message