3.0, the 2011 thread.

I think we have all joked on and off about 3.0 for... well about 8 years now. I think we are nearing the point we might actually need to be serious about it. The web is changed. SPDY is coming down the pipe pretty quickly. WebSockets might actually be standardized this year. Two protocols whic

Re: 3.0, the 2011 thread.

On 6/15/11 6:01 PM, "Paul Querna" wrote: > pocore: For base OS portability and memory pooling system. > How does this compare to APR? > libuv: Portable, fast, Network IO. (IOCP programming model, brought to Unix) > I've p

Re: 3.0, the 2011 thread.

On Wed, Jun 15, 2011 at 3:26 PM, Akins, Brian wrote: > On 6/15/11 6:01 PM, "Paul Querna" wrote: > >> pocore: For base OS portability and memory pooling system. >>   > > How does this compare to APR? It's like an APR version 3.0. It has a faster pools system, w

Re: 3.0, the 2011 thread.

On 16 Jun 2011, at 12:01 AM, Paul Querna wrote: I think we have all joked on and off about 3.0 for... well about 8 years now. I think we are nearing the point we might actually need to be serious about it. The web is changed. SPDY is coming down the pipe pretty quickly. WebSockets might

Re: 3.0, the 2011 thread.

On Wed, Jun 15, 2011 at 3:01 PM, Paul Querna wrote: > I think we have all joked on and off about 3.0 for... well about 8 years now. At least! > I think there are exciting things happening in C however. I love C, but unless we can come up with something radical, it's hard to see a way out of the

Re: 3.0, the 2011 thread.

+1 amen to reliability coming first. We run all kinds of awful code in production at the ASF, and httpd's design papers over that elegantly. Losing that would be a terrible blow to the utility of the project. Sent from my iPhone On Jun 15, 2011, at 7:33 PM, Graham Leggett wrote: On 16 Jun 20

Re: 3.0, the 2011 thread.

On 6/15/11 7:40 PM, "Colm MacCárthaigh" wrote: > Imagine > that in turn feeding into a set of co-routine filters. That's > fundamentally different - it parallelises content generation, but it's > really really hard to do in C. Depending on how far you want to push the model, it's not that hard.

Re: 3.0, the 2011 thread.

On 15 Jun 2011, at 23:01, Paul Querna wrote: > I think we have all joked on and off about 3.0 for... well about 8 years now. > > I think we are nearing the point we might actually need to be serious about > it. … > If we don't, I'm sure others in the web server market will continue to gain > ma

RE: 3.0, the 2011 thread.

> -Original Message- > From: Joe Schaefer [mailto:joe_schae...@yahoo.com] > Sent: Donnerstag, 16. Juni 2011 01:44 > To: dev@httpd.apache.org > Subject: Re: 3.0, the 2011 thread. > > +1 amen to reliability coming first. We run all kinds of > awful code in pr

Re: 3.0, the 2011 thread.

On Thu, 16 Jun 2011, Graham Leggett wrote: On 16 Jun 2011, at 12:01 AM, Paul Querna wrote: The problem is our process model, and our module APIs. Apache httpd has always had at it's heart the ability to be practically extensible, while remaining reliable, and I think we should continue to d

RE: 3.0, the 2011 thread.

Paul Querna [mailto:p...@querna.org] sent on Thursday, June 16, 2011 6:02 AM > > I think we have all joked on and off about 3.0 for... well about 8 years now. > ... > The problem is our process model, and our module APIs. > > The Event MPM was a valiant effort in some ways, but mod_ssl and other >

Re: 3.0, the 2011 thread.

On 6/16/2011 4:18 AM, bswen wrote: > > I think the only major problem of httpd is its "one thread per connection" > I/O model. It's an inherently unscalable design. Httpd-3.0 will be > meaningless if it keeps on this i/o design. That is no longer its design; it is now "one thread per request".

Re: 3.0, the 2011 thread.

On Thursday 16 June 2011, William A. Rowe Jr. wrote: > On 6/16/2011 4:18 AM, bswen wrote: > > I think the only major problem of httpd is its "one thread per > > connection" I/O model. It's an inherently unscalable design. > > Httpd-3.0 will be meaningless if it keeps on this i/o design. > > That

Re: 3.0, the 2011 thread.

Regardless of everything else, we *for sure* look at alternatives for some of what we're using now... I really, really, REALLY like the pocore-version of APR, and that would be a relatively quick and easy improvement. On Jun 15, 2011, at 6:01 PM, Paul Querna wrote: > I think we have all joked on

Re: 3.0, the 2011 thread.

On Wed, Jun 15, 2011 at 4:33 PM, Graham Leggett wrote: > On 16 Jun 2011, at 12:01 AM, Paul Querna wrote: > >> I think we have all joked on and off about 3.0 for... well about 8 years >> now. >> >> I think we are nearing the point we might actually need to be serious >> about it. >> >> The web is c

Re: 3.0, the 2011 thread.

2011/6/15 Colm MacCárthaigh : > On Wed, Jun 15, 2011 at 3:01 PM, Paul Querna wrote: >> I think we have all joked on and off about 3.0 for... well about 8 years now. > > At least! > >> I think there are exciting things happening in C however. > > I love C, but unless we can come up with something r

Re: 3.0, the 2011 thread.

On Thu, Jun 16, 2011 at 6:10 PM, William A. Rowe Jr. wrote: > On 6/16/2011 4:18 AM, bswen wrote: >> >> I think the only major problem of httpd is its "one thread per connection" >> I/O model. It's an inherently unscalable design. Httpd-3.0 will be >> meaningless if it keeps on this i/o design. >

Re: 3.0, the 2011 thread.

On 16 Jun 2011, at 10:27 AM, Stefan Fritsch wrote: I mostly agree with Graham. I propose a hybrid approach. Make the MPM and the network/connection filters (this includes ssl) event driven and keep the request handling based on threads and workers. We used openssl to make our non blocking e

Re: 3.0, the 2011 thread.

On 17 Jun 2011, at 6:14 PM, Paul Querna wrote: - Existing APIs in unix and windows really really suck at non blocking behaviour. Standard APR file handling couldn't do it, so we couldn't use it properly. DNS libraries are really terrible at it. The vast majority of "async" DNS libraries are

Re: 3.0, the 2011 thread.

On Friday 17 June 2011, Graham Leggett wrote: > We used openssl to make our non blocking event driven stuff work, > and it works really well (once you've properly handled > SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE). There is no reason > I can see that would stop us using openssl to be async in

Re: 3.0, the 2011 thread.

- Original Message - > On Friday 17 June 2011, Graham Leggett wrote: > > We used openssl to make our non blocking event driven stuff work, > > and it works really well (once you've properly handled > > SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE). There is no reason > > I can see that wo

Re: 3.0, the 2011 thread.

2011/6/18 Igor Galić : > > > - Original Message - >> On Friday 17 June 2011, Graham Leggett wrote: >> > We used openssl to make our non blocking event driven stuff work, >> > and it works really well (once you've properly handled >> > SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE). There is

Re: 3.0, the 2011 thread.

- Original Message - > 2011/6/18 Igor Galić : > > > > > > - Original Message - > >> On Friday 17 June 2011, Graham Leggett wrote: > >> > We used openssl to make our non blocking event driven stuff > >> > work, > >> > and it works really well (once you've properly handled > >> > SS