On Jun 23, 2011, at 4:56 PM, Chris Lalancette wrote:
> On 06/21/11 - 01:59:10PM, [email protected] wrote:
>> From: Michal Fojtik <[email protected]>
>>
>>
>> Signed-off-by: Michal fojtik <[email protected]>
>
> I took a quick look at this. Overall, the code looks sane (though see a
> couple
> of minor nits below). What I'm wondering about is how useful this will be to
> clients. At the moment I don't see condor/libdeltacloud using this as the
> only constraint we are interested in (user_name max_length) can be fetched via
> api -> instance link -> feature name='user_name' -> constraint. While this
> patch gives a more full range of parameters, I don't know how clients would
> use
> it exactly.
My original idea was to offer some kind of 'media-agnostic' form to create a new
resource to clients. Basically client don't know what parameters are need to be
send
in order to successfully create the new resource and it force developer of
client
to read documentation and search for the correct keys...
With this patch, client can fetch this XML and build a proper request for each
cloud provider we support. I'm also open to offer HTML and JSON form.
Actually I was looking for some 'standard' used to do this 'form' definition
thing.
-- Michal
>> ---
>> server/lib/sinatra/rabbit.rb | 7 ++++++-
>> server/views/api/constraints.xml.haml | 24 ++++++++++++++++++++++++
>> 2 files changed, 30 insertions(+), 1 deletions(-)
>> create mode 100644 server/views/api/constraints.xml.haml
>>
>> diff --git a/server/lib/sinatra/rabbit.rb b/server/lib/sinatra/rabbit.rb
>> index 5c1d757..007ba2f 100644
>> --- a/server/lib/sinatra/rabbit.rb
>> +++ b/server/lib/sinatra/rabbit.rb
>> @@ -221,7 +221,12 @@ module Sinatra
>>
>> ::Sinatra::Application.options("#{Sinatra::UrlForHelper::DEFAULT_URI_PREFIX}/#{name}")
>> do
>> operations_allowed = current_collection.operations.collect { |o|
>> o[0] }.join(',')
>> headers 'X-Operations-Allowed' => operations_allowed
>> - [200, '']
>> + @collection = current_collection
>> + @operations = @collection.operations
>> + @features = driver.features(@collection.name)
>> + respond_to do |format|
>> + format.xml { haml :'api/constraints'}
>> + end
>> end
>> end
>
> A couple of nits here.
> 1) Would we want to add an HTML/JSON output?
> 2) This code looks very similar to the next function
> (generate_documentation).
> Maybe we can have a common function that can do both? (not a huge deal, but
> I did notice the redundancy)
>
> --
> Chris Lalancette
------------------------------------------------------
Michal Fojtik, [email protected]
Deltacloud API: http://deltacloud.org
