Open Stack

On 06/10/2013 09:18 AM, Tal Kammer wrote:
> I fail to see how is it close to that model today.
>
> We have a lot of duplicate code in pretty much every implementation of XML vs JSON..
> what will happen if tomorrow we move to SOAP? do we really want to build a new client for every single component? (as it is now..)
 >
> if we look at the rest_client module as it is today, let's take the "identity_auth_v3" for example, what happens when a auth_v4 comes out? v5? do we just keep adding layers?

Identity v4 would presumably be different enough from identity v3, that 
there would probably not be a huge amount of code reuse. Nova v2 -> v3 
is a little bit breaking with this model.

> Having a model of a "Request" object (or any other name/object, the implementation itself is not relevant for the argument) immediately removes all duplication in clients (which is a lot of code), and a lot more code if we consider add ons in the future. (and I do believe we should consider the future..)
>
> Also, all response handling is hard coded, why not separate it into a class/module of it's own?
> Currently, if devs decide to change the response code, there is no graceful way of handling it. everything will pretty much fail..

Currently if devs decide to change the response code that's an API 
violation, and should be stopped. So optimizing for that use case really 
isn't the best idea.

> If we agree that things can be cleaner, why not start the cleaning process? If it's a matter of time, I am more than willing to volunteer.

I have no issues with cleanups. :) I'll happily review them.

I think the best place to go from here is some sample of what it would 
look like that could be concrete. Start with one of the smaller clients 
and work out from there.

I also really think this work needs to dovetail in getting us over to 
fixtures for testr. Jay already started with some ideas there, Matt's 
trying to drive some examples on the images clients.

I'm all for a more compact and cleaner code base to encourage additional 
development.

	-Sean

-- 
Sean Dague
http://dague.net