On 05/29/2012 06:26 PM, Geert Jansen wrote: > > > On 05/29/2012 03:44 PM, Michael Pasternak wrote: >> On 05/29/2012 04:14 PM, Geert Jansen wrote: >>> >>> >>> On 05/29/2012 12:12 PM, Michael Pasternak wrote: >>> >>>> there is no point in using this resource programmatically, as it only >>>> contains enumerations >>>> available in the system for given version and some other metadata, >>>> >>>> i.e it used by developers during the coding and it's not real system >>>> resource. >>> >>> I'm not convinced that that is true. For example, applications can use the >>> "power_managers" and "cpus" elements to prepopulate lists in a user >>> interface for example. >> >> this is good example indeed, then what about leaving /capabilities as is [1] >> only adding single resource retrieval capability [2] to comply with >> collection/resource >> pattern? >> >> [1] >> >> <capabilities> >> <version major="3" minor="1"> >> ... >> </version> >> <version major="3" minor="1"> >> ... >> </version> >> ... >> </capabilities> >> >> [2] >> >> /api/capabilities/UUID >> >> <version major="3" minor="1" id=UUID> >> ... >> </version> > > It would work from a compatibility point of view. However - to be honest - i > would leave it as it is now. You also have non-version specific capabilities > there, that do not > fit any model. In my view there is no way to get to a clean design here. > > The way i look at /api/capabilities is that is is a single global singleton > resource. It isn't a collection, and neither a resource in a collection.
it should have be collection of version_capabilities cause otherwise it not RESTful resource and inconsistent with other resources in api, as about /currently/ non-version specific capabilities: <permits> should be version specific as in new version will be added new permits and same for the <scheduling_policies>, can you remind me what was the reasons for making them such. > > Regards, > Geert -- Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
