Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 78327 invoked by uid 500); 3 Feb 2003 18:32:27 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 78212 invoked from network); 3 Feb 2003 18:32:26 -0000 X-Injected-Via-Gmane: http://gmane.org/ To: cocoon-dev@xml.apache.org From: Berin Loritsch Subject: Re: [OT rant] there must be some way out of here... Date: Mon, 03 Feb 2003 13:26:33 -0500 Lines: 41 Message-ID: References: <3E3EA533.1010102@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@main.gmane.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en In-Reply-To: <3E3EA533.1010102@apache.org> Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Gianugo Rabellino wrote: > Pier Fumagalli wrote: > >> >> Well, remember that now in Apache 2.0 mod_proxy and mod_cache are >> separated, >> so, if you achieve proxy "full support" using HTTP, you'll be able to >> simply >> replace the HTTP proxying module with something (Better? Faster? Is it >> really needed?), and keep all that caching magic working at the same >> time... > > > Yep. Apache mod_proxy (+ mod_cache) for the average, Squid for more > advanced users and Akamai for the huge boxes. :-) > >> >> The only case where I see something different from mod_proxy to be used >> would be in the case when you really need a lot of thrughput, and so >> you can >> use things like shared memory and unix sockets/pipes between Apache and >> Cocoon to basically avoid the re-parsing of the HTTP protocol and be as >> close to the client as possible (a some sort of mod_cocoon)... >> >> But of course that approach would mean having the Java code to rely on >> something native, with the rather-obvious problems of portability and >> maintainance... Quite complicated indeed... It wouldn't be 100% pure java >> anymore... > > > Just out of curiosity, what do you think of a NIO based, pure java, > lightweight HTTP server? I'm talking about projects like SEDA and > derivatives (http://sourceforge.net/projects/seda). Yep. Although I am officially part of that effort, I have not been able to do anything with it yet... My plans which seemed well received is to clean up the API and make Sandstorm more friendly to components. I am sure they will be happy for any help. --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org