Hi,
The implementation would be an alternate endpoint implementation, replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket channel (for AJP) will be provided. Development required is actually fairly small (significant testing will be required, however). I didn't do the updated socket channel yet, but after 3 days of hacking, HTTP works (and the AJP stuff should be much faster to do).
If it's truly independent, with an alternative PoolTcpEndpoint java class
and some additional dependencies (APR and the specific JNI wrapper), then
+1.
Yes, it is fully independent. I did end up modifying the Processor interface in coyote, but I think it is a useless interface. That's it.
At least for the first few releases, users should have the choice to use
this technology, and not have it be required. I think that's what you meant
anyways, just stating it for clarity.
I don't think it can ever be required. We'll see.
We can call it "experimental," advertise it, and get 3rd party (e.g. Peter Lin) benchmarks. It'd be a very nice selling point to have a non-blocking IO option ;)
Since the API stays really simple, you can go crazy on non blocking stuff.
R�my
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
