On 11/18/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: > > > > I'm not even sure if/how can we use OpenSSL via APR ( I found some > > code, and it should work ). The whole connection layer should be > > It actually works.
I'm happy I got regular HTTP/APR working, wasn't easy :-) > > > refactored to allow better abstraction for APR, NIO, old-style > > sockets/threads... The current approach in APR ( duplicate everything > > ) may be good for quick tests, but it can't be the long term solution > > ( some people like to add a NIO equivalent ). > > I'm perfectly fine with it. I prefer duplicating things than having a > complex abstraction layer (if you compare the APR API with the NIO/Java > IO API, you'll see APR is simpler, so the connector code can be a bit > simpler - for equivalent functionality at least). At this point, I see > non APR connectors as having no future production wise. So for NIO - we should create another copy of 5 large files ? Most of the functions are complete duplicates - a simple extend would eliminate them. The problems are in few abstractions - like Handler - which can be easily fixed to accomodate NIO / APR or traditional. NIO is a valid solution - and may be as fast as APR, in particular with JDK1.6 - and it avoids the JNI layer. I like APR more too - but I don't think it's wise to say there will be no better solution in the future :-) It just happens that today APR is faster - and has a lot of features beyond NIO. IMO the future is in features integrated at the low-level with the VM - in particular if they can bypass JNI or use non-garbage-collected heaps ( as in real-time java ). It would be hard for any JNI solution to beat this - but of course, that's future, not so easy to predict... Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
