On 04/10/2013 07:39 PM, David Lutterkort wrote:
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.
Yes, I meant tiny wrapper on top of drivers which abstracts from
internal driver changes/differences. Michal's dc-client is probably nice
example what methods (and with what parmas) I would expect from this API:
https://github.com/mifo/deltacloud-client/tree/master/lib/deltacloud/clie...
> 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.
The example you mentioned in a prev mail (instance start + poll_for)
looks like a handy feature to me, though more like an extension of this
basic lib.
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
Jan