On 05/16/2012 11:14 PM, Jay Dobies wrote: > What does this mean for your code? Not much actually. For normal calls > you still look at response.response_body to see the reply from the > server. For async calls, instead of calling things like is_postponed or > was_successful on the response object itself, you call it on the Task > which is in the response_body. So response.is_running() becomes > response.response_body.is_running(). I'm a lot happier about this since > it's the task that's waiting, not the response itself, it's just a > matter of making sure all of the existing calls have been migrated.
I'm wondering if it's worth streamlining this such that most client code doesn't need to *care* if it got an immediate response or not. The model that comes to mind is Twisted's Deferred objects and similar concepts in the concurrent.futures module and other "Promise" style APIs. The way that kind of approach would work is as follows: -- response_body would always be a JSON document (even for calls that returned a "queued" async result - in those cases, the response_body would still contain the JSON task details reported by the async call) -- a new "task" attribute would *always* be present, even for synchronous calls. In the latter case, it would be an implementation of the Task API that is preinitialised with all the info it needs rather than having to query the server for status updates. For guaranteed synchronous calls, you would access response_body directly (and "task" would always be None). For potentially asynchronous calls, client code would *always* go through the new "task" attribute (which would never be None). If the response happened to come back immediately, then the interface code takes care of that by providing an appropriate dummy Task object. Otherwise you're encouraging client code that has to do things like: if isinstance(response.response_body, Task): # Handle async case else: # Handle sync case It's cleaner if code can do: Use response.response_body if you want the received JSON data Use response.task if you want the task status Use "response.task is None" to identify synchronous responses This may mean you need a way to indicate in the JSON response itself that the content is a reply to a potentially asynchronous request. Regards, Nick. -- Nick Coghlan Red Hat Hosted & Shared Services, Brisbane _______________________________________________ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list