incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "marios@redhat.com" <mandr...@redhat.com>
Subject Re: [RELEASE] Deltacloud 0.1.0
Date Fri, 17 Dec 2010 15:22:59 GMT
Hi Toby,


On 17/12/10 17:06, Toby Crawley wrote:
> Congrats on the first Apache release!
>
> (more below)
>
> On Dec 16, 2010, at 6:24 PM, David Lutterkort wrote:
>
>> At long last, the release of Deltacloud 0.1.0 is available. The release
>> consists of four files total: the server and the Ruby client, in gem and
>> tgz format each. It can be found at [1]. There is also a detached GPG
>> signature for each of the files[2]
>>
>> This is the first release of Deltacloud as part of the Apache Incubator.
>> With this release, the Deltacloud API can also be considered stable -
>> any changes to the API in future releases will be done in such a way
>> that existing clients will work with a newer server, i.e. API changes
>> will be fully backwards-compatible.
>>
>
> I think this may need a little clarification. What constitutes the API? Is it the structure
and XML defined in [1], or does it include other items as well (response codes, specific collection/resource
xml, etc)? And what constitutes a client? Is it required to parse and respect the HATEOS links
in /api and further down, or will 'clients' that hardcode collection paths and ignore /api
be considered clients under this constraint?

not sure what you mean by 'the structure' - from where I'm standing its 
all of the above - that is, the abstractions that we present (aka 
'collections'/'objects') and their definitions, together with the 
operations permitted on those (complete with definition of the inputs to 
those operations, and expected output). This of course also defines the 
formats for the operations and their results.

With respect to 'clients' - well, we have already said we will maintain 
backwards compatibility. So if your client implements *some* version of 
the API, the fact that links are 'hard-coded' should be irrelevant - 
that is, they *should* correspond to/be compatible with whatever HATEOAS 
links we expose under /api (assuming we maintain the backwards 
compatibility constraint),

marios

>
> I understand the desire to pin down the API at an early stage, we just need to clarify
how much working room we have within those boundaries.
>
> [1] https://fedorahosted.org/pipermail/deltacloud-devel/attachments/20100812/8af80ac5/attachment-0001.pdf
>
>> Thanks to everybody who has contributed to Deltacloud, and to the
>> mentors for helping me find my way through the release process.
>>
>> David
>>
>> [1] http://www.apache.org/dist/incubator/deltacloud/0.1.0/
>> [2] To verify the signature, first download both the .asc file and the
>> corresponding artifact. Then, run a command like this:
>>
>>   gpg --verify $artifact.asc
>>
>> If that command fails because you don't have the required public key,
>> then run this command to import it:
>>
>>   gpg --keyserver keys.gnupg.net --recv-keys FC6E8A22
>>
>> and rerun the `gpg --verify' command.
>>
>>
>
> ---
> Toby Crawley
> tcrawley@redhat.com
>
>
>
>


Mime
View raw message