I just checked your pull request and in general I like what I saw and I think it's a step in the right direction.
Our goal should be to make the base classes as smart as possible so we can reduce amount of the repeated and Response munging code in the driver files. On Wed, Oct 19, 2011 at 2:33 PM, Caio Romão <[email protected]> wrote: > On Tue, Oct 18, 2011 at 6:22 PM, Paul Querna <[email protected]> wrote: > > On Tue, Oct 18, 2011 at 12:47 PM, Caio Romão <[email protected]> > wrote: > <snip> > >> Anyway, I believe some of those are done to circumvent bugs/API > >> oddities, but I think libcloud would benefit from standardizing (where > >> possible) how Request events are handled and this is where the "RFC" > >> in the title comes from. Would that be interesting? Anyone has any > >> ideas on this front? Can I work on that/ > >> > > > > In general yes, this is a very good thing to do. > > > > The examples of returning the body unparsed if its an unknown content > > type was done in several drivers because for example, they might > > return a 403, with a plain text message, but the rest of the API > > returns JSON. Some of those type cases don't have good test case > > coverage, and the response classes were kinda hacked around with as > > you can see in the inconsistenties. > > > > I think a base class for xml and json definitely makes sense, it just > > needs to be careful and have a few methods for falling back reasonably > > to not-parsing things > > > Conjecturing: > > Is adding logic to the Response class the best way to do this kind of > verification? I think having error handling logic in Response class is OK. Adding another class or something like that wouldn't really reduce the complexity or make error handling code more simple or clear. I'm definitely open to better ideas though. > I mean, this kind of logic seems to belong to something > else which handle errors. I.e.: if a driver expects a response might > come in plaintext, wouldn't it be better to leave the handling of that > to the driver per see? > This might be inviable since there are several uses of > self.connection.request, but putting all the logic inside the Response > class doesn't seem quite right to me. > > The state of the github branch I've mentioned keeps Response > self-contained (i.e.: I didn't have to change anywhere else besides > the specialized Response classes), however, the amount of logic I've > seen on the last commit ( > > https://github.com/caio/libcloud/commit/8bbc308d0a2c7e3d1310afefd39ef306d16c1d20 > ) bothered me a bit. >
