On Sep 14, 2012, at 5:07 PM, Michal Fojtik <[email protected]> wrote: > > On Sep 14, 2012, at 4:48 PM, [email protected] wrote: > >> >> notes: >> >> 1) moved supported_collection to base_driver and given it a credentials >> parameter >> >> 2) This means we can get rid of the Thread.current["credentials"] business >> altogether since the credentials are passed from the GET /api request so >> LazyAuth works as intended. >> >> 3) I kept the actual definition of 'supported_collections' as in the >> original >> - I don't see the benefit of changing this. The way I understand it >> currently: >> >> => each collection defines a lambda like : >> >> set :capability, lambda { |m| driver.respond_to? m }$ >> >> => the supported_collections method calls this lamba: >> >> m.settings.capability(index_operation_capability) >> (where 'index_operation_capability' is :buckets, in this case) > > This is correct. > >> So the result is supported_collections checks if a driver supports a given >> collection by calling respond_to?(collection_name) on the driver. Is this >> bad? > > I did it using lambda{} because it was the only way how to make it work with > the driver switching. The 'driver' method returns the 'current' driver and > since > the 'lambda' is evaluated in each request we can be sure we always check the > right (current) driver for the capability. > > Also this can lead to nice extensions, like using something more complicated > than just checking if method exists. > >> With these additions, each driver can just override supported_collections as >> David suggests anyway. > > Be careful about what happen when you switch the driver. It should always > return > to its original state. Mean you do a request for OpenStack which overrides > this method, > but then request to EC2 but the method will stay overridden.
Never mind this last comment, it is Friday and after I spend few more seconds on thinking about this patch I don't think this can happen ;-) -- Michal Michal Fojtik http://deltacloud.org [email protected]
