Sorry! "non-blocking" should have been "blocking" -- correction:
(John) > The separation of the client with the post/redirect/get pattern just > changes the *client* to a non-blocking 'future'-ish model. I.e., if > you use a thread pool model with a thread dedicated to processing the > entire set of checks and behaviors to handle the POSTed data vs. if > that's split out ala a SEDA approach, for example. (Lu) Exactly -- that's what I'm hoping to avoid, even though I agree it is a better design. The reason I want to avoid it is because I expect a non-trivial percentage of my clients not to have the skill to write a client like this. So I want to support a very simple REST client like curl, and provide a simple, ** blocking ** API spec. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1234344
