John Lenz <[email protected]> writes: >> Note that each of the backends obeys the same basic interface; what we >> need to do first and foremost is to abstract out the backend interface >> into a typeclass, then provide instances for libev and for the simple >> backend, and use the preprocessor to switch individual backends on and >> off. The config stuff will need to be extended to allow you to open N >> simultaneous backends on N ports. > > Ok, I didn't want to make major changes without at least some > feedback. One thing is that I don't think we want to duplicate the > entire backend for SSL support. If you look at my patch there are > only very minimal changes to simpleBackend and I expect the ev backend > to be similar. The SSL backend will have all the same code for > accepting, creating the event loops, monitoring timeouts, etc. The > only thing that changes is how we read and write the data plus a > little setup code.
Yes, any common code needs to get hoisted out into a Snap.Internal.Http.Server.BackendCommon module. Shouldn't be too big of a deal, just a little refactoring. > Perhaps we could split the backend into two apis, one class which takes care > of > the event loop > > perhaps something like > > class NetworkPort a where > bind :: a -> IO (Socket, CInt) > recv :: a -> Int -> IO b -> IO (Maybe ByteString) > send :: .... > whatever else is needed > > class EventLoop a where > attachListener :: (NetworkPort b) => a -> b -> IO () > waitForEvents :: a -> IO () > withConnection :: ... > other functions... > > Have two implementations of NetworkPort, one for normal sockets and > one for SSL and have two implementations of EventLoop, one the simple > backend and one the ev backend. Then we can create an event loop for > each cpu and attach ports depending on the config. I'm a little leery of typeclass dictionary overhead here, might be better to lift common accept/bind/whatever code into .BackendCommon and use it from other modules. You're correct that from a separation-of-concerns perspective event looping and sending/receiving/handshaking can be orthogonal. Maybe you could try it (with the appropriate SPECIALIZE pragmas) and load test it to make sure performance doesn't degrade? >> Re: SSL, I think that HOpenSSL is the safest bet here since you can >> reuse 99% of the SimpleBackend (although some common stuff will have to >> be lifted) but if you think an ssl-libev backend is easy also we should >> have that too. > > I think a direct binding to the ssl library makes the most sense > because of how low level we are working. I am not sure if the ev > backend can be made to work with HOpenSSL since HOpenSSL has a high > level interface and wants you to pass a socket and then just call the > API functions to read and write. For simple backend this would work fine, the functions from openssl are meant to mimic the BSD socket functions we're already calling. Re: GNU TLS: the "gnutls" hackage binding is GPL so I was worried about this, but reading your patch it looks like you've reimplemented the binding so I think we're ok from a license perspective right? G -- Gregory Collins <[email protected]> _______________________________________________ Snap mailing list [email protected] http://mailman-mail5.webfaction.com/listinfo/snap
