On Feb 6, 2014, at 4:07 AM, Graham Leggett <minf...@sharp.fm> wrote:
> On 05 Feb 2014, at 9:09 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> With http/2 becoming closer and closer, and spdy being >> in place as we speak, it seems that we should really >> ramp up development on trunk to support these new techs. >> >> Lets get serious on what needs to be done w/ trunk >> to get there, and what our wish-list is for new capability >> and architecture. >> >> Taking a page from mod_spdy, breaking the connection->request >> singularity looks like an interesting 1st step, maybe via >> some sort of "virtual connection" which a real connection >> can spin up/down and which corresponds to the request's >> "actual" connection... > > My moon-on-a-stick wishlist is as follows. > > I want more from the MPMs. Most specifically, what I want is: > > - The ability to create and associate additional connections with the > original incoming connection, creating a set of associated connections, all > controlled by the same event loop. > > If mod_proxy wants to make a connection, I want to be able to tie it into the > same event loop that is driving the frontend. It should not matter where the > connections come from, they could be local pipes, doesn't matter. Not only connections but also threads, that are treated as typical MPM threads. > > - The ability to mask events. > > Messing around with lists of sockets is a colossal faff, ideally the MPM > should worry about this and the module developer shouldn't care. What I want > is the ability, at any time, to mask an event on a connection in a simple and > easy to understand way. > > While I am waiting for a ready-to-read from a backend proxy, I want to mask > the ready-to-write to the frontend, and I don't want this to be fiddly. > > - First class support for openssl. > > The SSL protocol is a layer, meaning that while we may be trying to read, > openssl underneath might be trying to either read or write to perform a > renegotiation. What openssl asks us to do is switch to a write in the middle > of a read, or a read in the middle of a write. > > We must support this properly from the get go with the ability to override > the sense of any event from a write to a read or a read to a write. In the > past the MPMs have ignored openssl expecting to handle it as some kind of > special case, and this is wrong. > > Regards, > Graham > -- >
