Hi all, I'm continuing with the work on the JSON rendering (I attached the latest version). I'm currently reviewing the rendering of entities. I was wondering, if we could use "Collection" for rendering single entities as well. On the other hand, we might as well drop the Collection completely and just use an array of entity renderings. I would prefer using the term entities, as the rendering is then similar to the rendering of the categories (with "kinds" and "mixing"). What do you think? e.g. instead of using { "collection": [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ] } we could use either: { "entities": [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ] } or just: [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ] Cheers, Florian ------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de<http://www.gwdg.de> ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------
Hi What phases of the life cycle are these referring ? 1) To the provider's capabilities definition ? 2) The consumer's request for service ? 3) The instantiation of a consumer's implementation ? 4) The consumer's configuration at the service provider ? 5) All of the above ? I raise the questions based on the appropriateness of the parent object's term to use cases. We may want to consider naming the parent object in the examples so we can assess the approach in terms of use cases. My personal preference is to have a "Collection" with a name property. How would this look with hierarchical or peered collections ? cheers, gary On 2/22/2012 8:16 AM, Feldhaus, Florian wrote:
Hi all,
I'm continuing with the work on the JSON rendering (I attached the latest version).
I'm currently reviewing the rendering of entities. I was wondering, if we could use "Collection" for rendering single entities as well. On the other hand, we might as well drop the Collection completely and just use an array of entity renderings. I would prefer using the term entities, as the rendering is then similar to the rendering of the categories (with "kinds" and "mixing"). What do you think?
e.g. instead of using { "collection": [ { "kind: { ... }, "mixing": { ... }, "actions": { ... }, "attributes": { ... } }, { "kind: { ... }, "mixing": { ... }, "actions": { ... }, "attributes": { ... } } ] }
we could use either: { "entities": [ { "kind: { ... }, "mixing": { ... }, "actions": { ... }, "attributes": { ... } }, { "kind: { ... }, "mixing": { ... }, "actions": { ... }, "attributes": { ... } } ] }
or just: [ { "kind: { ... }, "mixing": { ... }, "actions": { ... }, "attributes": { ... } }, { "kind: { ... }, "mixing": { ... }, "actions": { ... }, "attributes": { ... } } ]
Cheers, Florian
------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen
Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de <http://www.gwdg.de> ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hi Gary, Am 22.02.2012 um 16:54 schrieb Gary Mazz:
Hi
What phases of the life cycle are these referring ?
1) To the provider's capabilities definition ?
no, but in my opinion the entity rendering should be similar to the capability definition.
2) The consumer's request for service ?
yes, in my opinion the rendering should have the same structure (e.g. "collection" or "entity" with an array of the elements, even if there is only one element in the array) for GET / GET /compute/ GET /compute/123 With Ralfs implementation, there is currently a difference between GET / or GET /compute/ and GET /compute/123 The latter one is only the rendering of the entity without it being embedded in an collection or entity array.
3) The instantiation of a consumer's implementation ?
It should be the same. Ralf already described it in 5.2.1 Client POST request. There is currently a collection array.
4) The consumer's configuration at the service provider ?
What do you mean with configuration?
5) All of the above ?
No.
I raise the questions based on the appropriateness of the parent object's term to use cases. We may want to consider naming the parent object in the examples so we can assess the approach in terms of use cases.
My personal preference is to have a "Collection" with a name property.
I don't like the idea of having a name property. The current way with having keys named "kind", "mixins" is fine for me.
How would this look with hierarchical or peered collections ?
I'm not sure about hierarchical collections. In general, we have the approach to show all entities below a given path, right? Thus GET /compute/florian/ would show a subset of the resources shown by GET /compute/ I haven't head much discussion regarding hierarchies. Currently I don't see anyone using them. It might be handy to have a way of discovering hierarchies without retrieving all resources. Something like a directory listing. Any thoughts on this?
cheers, gary
On 2/22/2012 8:16 AM, Feldhaus, Florian wrote:
Hi all,
I'm continuing with the work on the JSON rendering (I attached the latest version).
I'm currently reviewing the rendering of entities. I was wondering, if we could use "Collection" for rendering single entities as well. On the other hand, we might as well drop the Collection completely and just use an array of entity renderings. I would prefer using the term entities, as the rendering is then similar to the rendering of the categories (with "kinds" and "mixing"). What do you think?
e.g. instead of using { "collection": [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ] }
we could use either: { "entities": [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ] }
or just: [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ]
Cheers, Florian
------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen
Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list
occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hi Gary,
Am 22.02.2012 um 16:54 schrieb Gary Mazz:
Hi
What phases of the life cycle are these referring ?
1) To the provider's capabilities definition ? no, but in my opinion the entity rendering should be similar to the capability definition. If they are different, any differences, this needs to be clearly defined and differences clearly noted. It effects usability
2) The consumer's request for service ? yes, in my opinion the rendering should have the same structure (e.g. "collection" or "entity" with an array of the elements, even if there is only one element in the array) for GET / GET /compute/ GET /compute/123
With Ralfs implementation, there is currently a difference between GET / or GET /compute/ and GET /compute/123 The latter one is only the rendering of the entity without it being embedded in an collection or entity array. I agree with you on this topic, minimize any differences to ease implementations.
3) The instantiation of a consumer's implementation ? It should be the same. Ralf already described it in 5.2.1 Client POST request. There is currently a collection array.
4) The consumer's configuration at the service provider ? What do you mean with configuration? At a provider, a consumer can upload an OVF file with a complex "configuration" of VMs. As a consumer, I can instantiate any number of VMs. I can also download my set of configured VMs in an OVF file with
On 2/22/2012 9:52 AM, Feldhaus, Florian wrote: the associated disk images. The OVF is a definition file of the VM configurations.
5) All of the above ? No.
I raise the questions based on the appropriateness of the parent object's term to use cases. We may want to consider naming the parent object in the examples so we can assess the approach in terms of use cases.
My personal preference is to have a "Collection" with a name property. I don't like the idea of having a name property. The current way with having keys named "kind", "mixins" is fine for me.
We would have to use a mixin, I wanted to see what your thoughts were on the taxonomy (structure) of the JSON data. One issue we have never addresses is the intuitiveness of the data and the challenges faced by implementers accessing the data in the native forms.. If the data structures are convoluted and difficult to understand, it poses an barrier to widespread adoption.
How would this look with hierarchical or peered collections ? I'm not sure about hierarchical collections. In general, we have the approach to show all entities below a given path, right? Thus GET /compute/florian/ would show a subset of the resources shown by GET /compute/
I haven't head much discussion regarding hierarchies. Currently I don't see anyone using them. It might be handy to have a way of discovering hierarchies without retrieving all resources. Something like a directory listing. Any thoughts on this?
Ahh... Vmware's new administration products allows you to organize virtual machines in arbitary groups, a very desirable feature when assessing costs and risks.
cheers, gary
On 2/22/2012 8:16 AM, Feldhaus, Florian wrote:
Hi all,
I'm continuing with the work on the JSON rendering (I attached the latest version).
I'm currently reviewing the rendering of entities. I was wondering, if we could use "Collection" for rendering single entities as well. On the other hand, we might as well drop the Collection completely and just use an array of entity renderings. I would prefer using the term entities, as the rendering is then similar to the rendering of the categories (with "kinds" and "mixing"). What do you think?
e.g. instead of using { "collection": [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ] }
we could use either: { "entities": [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ] }
or just: [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ]
Cheers, Florian
------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen
Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list
occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
On Wed, 22 Feb 2012 15:16:28 +0000, "Feldhaus, Florian" <florian.feldhaus@gwdg.de> wrote:
I'm currently reviewing the rendering of entities. I was wondering, if we could use "Collection" for rendering single entities as well. On the other hand, we might as well drop the Collection completely and just use an array of entity renderings. I would prefer using the term entities, as the rendering is then similar to the rendering of the categories (with "kinds" and "mixing"). What do you think?
I used the word "collection" just to avoid confusion. OCCI Core says that a bunch of entities of a certain type (say Compute) automatically form a collection. This however was not entirely obvious at first glance so I wanted to make it clear that OCCI indeed have collections. I do not understand the reason for having the same representation for collections as for single resource responses. What is wrong with: GET /resource-ID { resource } GET /collection/ { collection: [ resource1, resource2, ... ], size: 1004, // total number of items in the collection, not in the response start: 0, } E.g. how do you get just the size of a collection? Like this: GET /collectionX/?count=0 ... { collection: [], size: 1004, start: 0, }
e.g. instead of using { "collection": [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ] }
I still vote for this yes.
or just: [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ]
This we cannot have. It is a security issue to return a JSON arary at the top level. There is an old thread on occi-wg on that as well. regards, Ralf
Comment below On 2/23/2012 6:29 AM, Ralf Nyren wrote:
On Wed, 22 Feb 2012 15:16:28 +0000, "Feldhaus, Florian" <florian.feldhaus@gwdg.de> wrote:
I'm currently reviewing the rendering of entities. I was wondering, if we could use "Collection" for rendering single entities as well. On the other hand, we might as well drop the Collection completely and just use an array of entity renderings. I would prefer using the term entities, as the rendering is then similar to the rendering of the categories (with "kinds" and "mixing"). What do you think? I used the word "collection" just to avoid confusion. OCCI Core says that a bunch of entities of a certain type (say Compute) automatically form a
collection. This however was not entirely obvious at first glance so I wanted to make it clear that OCCI indeed have collections.
I do not understand the reason for having the same representation for collections as for single resource responses.
What is wrong with:
GET /resource-ID { resource }
GET /collection/ { collection: [ resource1, resource2, ... ], size: 1004, // total number of items in the collection, not in the response start: 0, }
E.g. how do you get just the size of a collection? Like this: GET /collectionX/?count=0 ... { collection: [], size: 1004, start: 0, }
There is nothing technically "wrong" with it, it just sucks as a client to figure out if you have an array or resource. CDMI had the same issue and decided for the array of one element....
e.g. instead of using { "collection": [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ] } I still vote for this yes.
or just: [ { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }, { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } } ] This we cannot have. It is a security issue to return a JSON arary at the top level. There is an old thread on occi-wg on that as well.
regards, Ralf _______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
On Thu, 23 Feb 2012 07:52:09 -0700, Gary Mazz <garymazzaferro@gmail.com> wrote:
There is nothing technically "wrong" with it, it just sucks as a client to figure out if you have an array or resource. CDMI had the same issue and decided for the array of one element....
hmm, so you are saying your client immediately forgets what it asked about in the request and must figure that out from the format of the response? I suppose that is a HTTP-ish way if implementing things, yes. But then it is better to fix this with proper media-types for each response type as previously proposed by Florian. E.g.: Content-Type: application/occi-entity+json Content-Type: application/occi-collection+json Content-Type: application/occi-discovery+json regards, Ralf
+1 simple is good With regard to the get request, is it legal to specify the accept content type using wildcards in this manner: "application/occi-*", or would we have to just add multiple entries on the line? Ralf Nyren wrote:
On Thu, 23 Feb 2012 07:52:09 -0700, Gary Mazz<garymazzaferro@gmail.com> wrote:
There is nothing technically "wrong" with it, it just sucks as a client to figure out if you have an array or resource. CDMI had the same issue and decided for the array of one element.... hmm, so you are saying your client immediately forgets what it asked about in the request and must figure that out from the format of the response?
I suppose that is a HTTP-ish way if implementing things, yes.
But then it is better to fix this with proper media-types for each response type as previously proposed by Florian.
E.g.: Content-Type: application/occi-entity+json Content-Type: application/occi-collection+json Content-Type: application/occi-discovery+json
regards, Ralf
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
On Thu, 23 Feb 2012 23:36:44 -0500, Michael Behrens <michael.behrens@r2ad.com> wrote:
+1 simple is good With regard to the get request, is it legal to specify the accept content type using wildcards in this manner: "application/occi-*", or would we have to just add multiple entries on the line?
Good observation. The only wildcards allowed by RFC2616 [1] are (for our use case) */* and application/*. Neither of those is specific enough to distinguish between different OCCI Renderings. You would have to specify all three of them or just the one relevant to the request made. E.g. if you do GET /-/ you could just specify Accept: application/occi-discovery+json since that is what you were after anyway. regards, Ralf [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
participants (4)
-
Feldhaus, Florian -
Gary Mazz -
Michael Behrens -
Ralf Nyren