jxstanford
|
Posted: September 30, 2009 23:43 by jxstanford
|
|
I've been working on a data model based on the cloud API, and was wondering about the vm_templates. The vm_templates URI attribute of the VDC seems a bit clunky. This might just be the way I'm looking at it, but I don't seen any other places in the model where a URI is included as an attribute to access a list of things. The locations attribute of Cloud resource is an example of what seems more intuitive to me. What was the reasoning behind making vm_templates a URI? Is it because the list is expected to be fairly long? If so, this might fit into the " Query Parameter for "Compact" Representations" discussion. Or maybe the perceived usage of the GET will be more about listing the VMs rather than the VM templates? Also from a previous post: Later when there are user developed templates (private), and possibly purchased templates (cloud store), in addition to the ones provided by the cloud. Is there a need to distinguish these different types of templates in the data model? |
why does VDC have a vm template uri?
Replies: 2 - Last Post: October 01, 2009 14:15
by: jxstanford
by: jxstanford
showing 1 - 3 of 3
Tim Bray
|
Posted: October 01, 2009 02:30 by Tim Bray
|
|
You're exactly right; the worry is that the template catalog could be very large, and you don't want to give it to someone unless they ask for it. As to your other question: there's been a proposal that the vm_templates field should actually be a list of URIs, to support multiple catalogs. Opinions? |
jxstanford
|
Posted: October 01, 2009 14:15 by jxstanford
|
| I think the vm_templates should enable hierarchy. This would allow templates to be organized similar to a folder tree. So the vm_templates may return one URI (the root of the template tree), but have two possible types of elements underneath it -- a template or another URI. |
Replies: 2 - Last Post: October 01, 2009 14:15
by: jxstanford
by: jxstanford







