I think Jetty had an intersting approach on this, with their so called 'continuation'. I didn't like their use of exceptions to control the flow.
+1 on adding the functionality ( as long as you're ok with eventually adding the same on the nio connector on sandbox :-), but it would be great to review the proposed API that servlets will need to implement. For example, I would assume what you need is: 1. a servlet to tell tomcat to not close the connection ( "I'm not done, but I'm going to sleep waiting for events for a while" ) 2. a way for a thread/event to tell tomcat to resume a particular request, and 3. a way for tomcat to wake up a servlet if some activity happens on the client side. For 1 - I assume a tomcat-specific API or (special) request attribute is needed ( and service() to return ). Jetty uses a special exception, I don't think it's a good idea. For 2 - any reason for new API ? Could it just use the saved response object ? For 3 - ??? Call service again with an extra attribute ? Require servlets to implement an interface or to register with tomcat a callback ( maybe using setAttribute when going to sleep ) ? Costin On 5/16/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
Costin Manolache wrote: > For those of us who don't know much about 'comet' - could you explain a bit > more ? > A small example, some pointers to what APIs are needed ( if it's not > service > ), > why service doesn't work, etc. There's some documentation here: http://alex.dojotoolkit.org/wp-content/LowLatencyData.pdf The (only) actually useful capability is of course to push back data at any time. To replicate the same with regular servlets, you need a forever running service method, which doesn't work that well. It's really evil-hype-powered stuff, and I think it's all your company's fault :( However, since my attempts at SIP (which has the same biderectional capabilities without the hacks, of course) miserably failed, and since it's not too hard to implement in the APR connectors, I think it should be done (the API right now is an interface that the servlet should implement, but I plan to provide a ready to use abstract servlet which should be easy to work with). Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
