> It's probably best in that case for handle to return a Future-like object > that lets you wait for completion or cancel. Then Restlets that implement > asynchronous handle could use a common default implementation of synchronous > handle like this ... >
That's the general idea I had in mind ... glad you have the same picture. I don't want to lose the simple synchronous version either. There need to be thread-safe versions of Request and Response for any of > this to work. > I believe there need to be thread-safe versions of Request and Response (full stop). Given an architecture like Restlet that allows considerable creativity in the client and server connectors you plug in, I'd like to have some guarantees about the concurency behavior of high level API objects, regardless of how interesting the implementation of the underlying call is. I should probably put these and future comments in the issue tracker, but > for which issue, > asynchronous<http://restlet.tigris.org/issues/show_bug.cgi?id=143>or > GWT <http://restlet.tigris.org/issues/show_bug.cgi?id=127>? > The async RFE would be the best choice, IMO. GWT is a special case that effectively requires callbacks for implementation reasons, which turns out to make a handy testbed for some of these concepts, but the overall async thinking should be driven by the async RFE. - R
