Hi Vincent,
Thanks for the quick feed-back. WebSocket due to its official IETF status and early support in modern browsers is very promising, and there is the Server-sent events spec part of HTML 5 that I like much due to its smart leverage of HTTP, compatible with the REST style. In your case, I would indeed recommend the new NIO connector for development purpose and Jetty for production. I hope to fully stabilize the NIO connector very quickly so it can be recommended for production in the near future (this is a strong goal for us). Regarding Netty, we are only dropping it from an HTTP point of view, but if it makes sense to build new connectors on top of it, we’ll happily leverage it. This is definitely a great IO framework. Our NIO connector has also been designed to be reusable outside pure HTTP cases. For example, support for SIP/TCP and SIP/UDP on top of it as an immediate 2.1 goal. Best regards, Jerome -- Restlet ~ Founder and Technical Lead ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ <http://www.noelios.com/> http://www.noelios.com De : Vincent Nonnenmacher [mailto:[email protected]] Envoyé : mardi 2 novembre 2010 19:07 À : [email protected] Objet : Re: Removal of extensions for upcoming versions Second attempt without the typos J --- Hi all, While preparing for the release of Restlet Framework 2.1 M1 (due tomorrow), I’ve done some clean-up and removed modules that we won’t develop or support anymore. The goal is to focus our energy on the modules adding the most value to end-users rather than trying to integrate with everything cool technology around. I first had a look at the incubator and saw three modules that aren’t developed anymore: JXTA : technology for peer-to-peer networks which hasn’t evolved much since 2007 Shell : command line support for Restlet, which we prefer to cover using IDE tooling <http://wiki.restlet.org/developers/172-restlet/361-restlet.html> in the future Atmosphere : mostly empty, dependency on Servlet API, too much to do, too much overlap with the asynchronous Restlet API features… but interesting project to keep an eye on :) implementing a websocket connector on top of restlet would be a much less loss of band(cpu)width ;-) Atmostphere is too much oriented toward jersey and the dependency on the servlet even if it could be aleviated it is too much of work for a technology that have now less attraction (read tech lust) than websocket as a lot of libraries could make it available even for old browsers through a flash proxy. In addition I would like to remove the Grizzly and Netty extensions which were considered as experimental connectors in Restlet Framework 2.0. The new internal connector <http://wiki.restlet.org/developers/172-restlet/354-restlet.html> based on non-blocking NIO that will be available in version 2.1 M1 now provides similar advantages (fully decoupling HTTP connections and IO threads) and is already more complete from a HTTP coverage point of view. Relying on our own connector also has many advantages such as control of the IO/network layer allowing features such as TCP/IP connection blocking which would be possible a consistent manner across all extension connectors. I use Grizzly (for not good reason anymore) what is your suggestion for current development (i.e not in production) abandon it and switch to jetty as a safe bet for production cases and play with your new baby in developpement to test it ? ps : to bad you droped netty as it could be used outside of the http case for communicating with plain old socket oriented servers as it is more supported than apache mina. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2678122
