deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Provazník <jprov...@redhat.com>
Subject Re: deltacloud as a lib and broker
Date Thu, 11 Apr 2013 10:53:32 GMT
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/client/methods

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

Mime
View raw message