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 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.
