[Pulp-list] Client Connection API Change

[Jay Dobies]

Short version: If you've written an extension that used APIs that may or 
may not return async responses, that returned object changed. I _think_ 
I fixed all of them but you might want to take a look over your code. 
Jeff, you in particular I know was in this area for consumer install and 
might want to take a look.

Long version: My original idea for the responses coming out of 
client-side bindings calls didn't hold up. Originally it returned one of 
two object types, a Response or an AsyncResponse. All of the task 
interpretation methods (queued v. running, etc.) lived in the 
AsyncResponse directly.

That fell apart the moment I tried to write the APIs to retrieve the 
status of a task. In some calls we can have multiple tasks in a single 
response, all of which had different states. And it broke the model to 
have it return multiple AsyncResponse objects.

So the new model is as follows:

- Every call into the client-side bindings returns a Response. That 
object currently contains the http status code and response body, though 
I can see in the future adding in details of the request itself so we 
could have a resubmit sort of concept. Error codes still raise 
appropriate client-side exceptions to reflect the problem.

- There is a method in Response called is_async that tells you if the 
response ran and completed or if it was queued on the server. This may 
be better called "is_queued" if anyone feels strongly; I struggled with 
the name a bit.

- The response_body value in Response will be one of two things (for 
now, maybe more in the future):

-- The JSON document for the response. This is the common case where you 
get something back from the server.

-- A Task object which is where all of the CallReport parsing and data 
interpretation methods moved.


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.

-- 
Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org