[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Pulp-list] Client Connection API Change



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]