Hi Tim, The idea is to let the developer, on the server-side, release the calling thread if he is planning to block for a long time for another service before being able to prepare the response. He would mark the Response to indicate that it isn't ready to be sent/committed to the socket. When the invoked service returns (in an asynchronous way as well but on the client-side), it would callback the Resource/Restlet and let it mark the Response instance as ready to be sent/committed. This would trigger an action on the server connector that would wake up and write the response on the output socket. Now, this only covers part of the asynchronous needs. We also need to cover the client-side. We would probably use something similar to what we did for the Restlet-GWT port: use a callback mechanism. We should also leverage the Future interface as you previously suggested. Am I missing something? Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com
_____ De : [email protected] [mailto:[email protected]] De la part de Tim Peierls Envoyé : mercredi 7 janvier 2009 21:14 À : [email protected] Objet : Re: Restlets and Asynchronous Request Processing Jérôme, Could you elaborate on your most recent comments in the "Support asynchronous processing" issue? http://restlet.tigris.org/issues/show_bug.cgi?id=143 In particular, what would the Response autoSent property mean? --tim ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1024734
