On 09/09/10 15:18, Maxime Bégnis wrote: > Thanks Vincent for your tips. I'm looking forward to this > implementation of NIO. > > Regards, > > Maxime Bégnis > I looked at your Calenco projet and see that you are using Dojo so it's true that you can favor comet instead of websocket as dojo is far more advanced on the subject than say jQuery (which is my choice).
For doing comet using Restlet I'm now (regarding that I don't use jetty that could change the deal completely I admit) pursuing the idea of having the UI (and so the comet/websocket real time update) be done by an other small server (Ruby based) in scheme where Restlet is used as the 'controled model' and the web-client subscription (done either automaticaly by bayeux subscription or websocket channels) is handled by this layer. So Restlet stay in its own paradigm. In such scenarii you could have this second server having some active 'subscription' from the Restlet engine in term of a REST request that carry what URI this server want to be notified of some events. The second server controling the UI-serving will itself do the comet/websocket handshake. like in : 1) [ ressources + inside/business events flow ] <--> RESTful interface using Restlet 2) comet/websocket reactor <--> Web clients and 2) make request to 1) like POST /uripath/<monitored ressource/event>/notification with a REST Request URI that will be accepted by 2 then whenever there is a ressource change or event concerning the 'monitored' ressource 1) will just place the request (as a client) with a aggreed uppon paylod (for example a RessourceRef). Then 2) could ask for more details using your own API. This is in par with idea like the PubSubHub[Hub] things. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2657216
