Yah, this brings up an issue that several of the methods actually will
need to deal with.
In general, I assume we want to support filtering results via query
arguments, perhaps across any of the attributes on any resource.
Instead of images(creds, ids), perhaps better to have images(creds,
opts=nil)
Then, fetching by id or fetching by owner or fetching by architecture
would all work the same way. Or a combination of such.
ie,
images( creds, { :owner=>:self } )
images( creds, { :ids=>[1, 23, 42, 99] }
images( creds, { :owner=>8675309 } )
images( creds, { :owner=>:self, :architecture=>:x86_64 }
With the default nil opts,
images( creds ) # fetches them all
Same for flavors, instances, etc.
-Bob
On Aug 6, 2009, at 8:12 AM, Bryan Kearney wrote:
Manik Surtani wrote:
> On 5 Aug 2009, at 21:36, Bryan Kearney wrote:
>> I would like to discuss the driver SPI. It is a bit too EC2ish (I
>> think):
>>
>> the images call is
>>
>> images(credentials,ids)
>>
>> where ids can be either a ownerid or an image id.
> Can you not determine what the ID is based on a pattern? AFAIK
> this is how EC2 does this.
I may be able to.. but if the goal is to make this a driver agnostic
api, I would suggest we be a bit more typed (if you can call a
collection of key/value pairs typed)
-- bk
_______________________________________________
Libcloud-list mailing list
Libcloud-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libcloud-list