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>
>
>>>
>>> In your proposal, are you leaving /api/capabilites in place as it is now?
>>
>> no, please see new modelling below.
>>
>>> If not how to you enumerate the different versions?
>>
>> since our resource id is opaque by definition - it doesn't have to be UUID,
>> the id for version_capabilities resource can be the version itself, i.e 3.0
>> / 3.1 / etc.
>>
>> (worst case if someone likes UUID more we can convert version str. to UUID)
>
> How do you get a list of which IDs / versions are available?
by listing all <version>s as today only adding id/href to it,
/api/capabilities
<capabilities>
<version major="3" minor="1" id=xxx href=/api/capabilities/xxx>
...
</version>
<version major="3" minor="1" id=yyy href=/api/capabilities/yyy>
...
</version>
...
</capabilities>
i.e same as for any resource in api.
>
> Regards,
> Geert
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
