Hi Martin, On Wed, 2013-04-10 at 15:53 +0200, Martin Povolny wrote: > I think that Jan's original idea was to expose sort-of-cleaned-up driver > API as the universal library API. > > That is mainly work through the controller methods that implement the > API calls and > > * identify and fix the places where there is any other code then such > that parses and passes the inputs, outputs and error state between > the REST remote call and the drivers. > * unify the driver interface where differences exist > > Then just provide some class that basically delegates everything to a driver.
If by 'delegate' you mean 'wrap', i.e. have a tiny little bit of logic in between that allows us to adjust to changes in the driver API, then yes. Just as an example: we recently went through and made driver methods return empty arrays in a lot of places where they used to return nils. We need to have a place where we insulate library users from these sort of changes. > As I read it, what you suggest is implementing a Ruby-style API on top > of the cleaned-up driver API. > > Having such layer on top of that is not what Jan suggested, but it would > surely be convenient from consumer point of view. > > Also it would allow more changes in the driver API if the Ruby-style API > would be what is advertised as "the thing" to the community. The > Ruby-style API could then be the "air bag" that keeps the backward > compatibility even if the driver API changes. > > I personally like the idea as it is surely more Ruby-dev (community) > friendly. But it is then a thing of a wider scope. > > We should probably take a look at other libraries out there (both > provider-specific and sort-of-universal, such as the Fog) to see the > programming idioms that people might be already used to. The reason I suggested the more Ruby-ish API is that I agree that we might be able to attract more people with the library API, but I don't think the current driver API is very attractive for that. Geemus used to be very proud of the fact that Fog exposes a AR-inspired API - that's the kind of thing we should aim for here (not that I think AR is the right metaphor, but it's a good inspiration) David
