On Wed, 29 Feb 2012 12:23:25 +0100, Feldhaus, Florian <florian.feldhaus@gwdg.de> wrote:
Hi Ralf,
Hi Florian and thanks for the update!
at todays Plugfest Jamie Marshall, David Slik, Houssem Medhioub, Andy Edmonds, Thijs Metsch and I discussed about the JSON rendering. Your proposal was well received. For the entity rendering there was the suggestion to make it more intuitively usable. The main difference is, that the attributes should be directly accessible by name structure. e.g. make it possible to do the following commands in your favorite programming language: var occi = GET /compute/123 occi.kind occi.compute.cores occi.my_mixin.my_attribute
Yes, would be really nice if we could get something like that to work.
The only thing we have to prohibit then is, that a single service provider has mixins from different domains with the same term and attributes.
This is the hard part. I cannot see a way to do this without changing fundamental parts of OCCI Core :-\ Today we have 2 name-spaces where conflicts could arise: 1. Entity sub-types 2. Attributes 1: For entity sub-types we have a categorisation schema (as part of the Kind/Mixin identifier) which allows arbitrary naming within the schema. E.g. you could have 100 providers interacting and sharing resources which each of them have their own "compute" type (term="compute"). It works since they are forced to have unique categorisation schemas. Let's assume for a minute that we would drop the categorisation schema and only have the "term" left. We prohibit anyone from using resource, link, compute, storage, etc since we have defined them already. Later on we want to add a new infrastructure type but since it was not forbidden from the beginning adding a new type could break interoperability. So the system falls apart without the categorisation schema. 2: For attributes we have another name-space saying that anything starting with "occi." is reserved and any custom attributes MUST start with the reversed domain name of each provider, e.g. "com.example.". Again, if we drop the attribute prefix requirement we can no longer control future additions of attributes in the OCCI spec. If you say that a particular provider must not have conflicting attribute names _today_ he may for example add a "ipv6" attribute. Now if we decide to add a new attribute, e.g. "ipv6", to a future version of OCCI Infrastructure we can never know if there isn't a service provider out there who already have that attribute in use (with different semantics). Therefore we would not be able to add anything and guarantee backwards compatibility. Please feel free to prove me wrong, I would be glad if you did. Now what we _could_ do is to instead of saying "compute": { "memory": 4, ...} we would say: "http://schemas.ogf.org/occi/infrastructure#compute": { "memory": 4, ... } That would work but require more bytes on the wire in most cases. It actually combines the two name-spaces into a single one which is nice though. What say you?
In the category rendering we proposed to use special parameters for different attribute types. e.g. having min_length and max_length for strings and an array of bounds for integers or floats.
Different restrictions for different types, sure. I would just make a slight modification and say, e.g.: "string": { "min_length": 4, "max_length": 32 } That way it is much easier to strictly specify which restrictions apply to which type. Could you make a list of the restrictions applicable to each of the defined attribute types?
Here are some ideas: http://pastebin.com/y2K7bu1S
I do not really see the purpose of the URL list format you call "collection". You already have this with text/uri-list. In the collection example you call "entities" you use a JSON array at the top level. This is a security problem and must be avoided. That is partly why I choose to say { "collection": [ ... ] }. Basically if you always have an json object at the top level silly people doing eval() on the received json data will be kept safe. I see you made the format really lean which is nice. How did you intend to render Link attributes?
I like the "choices" property, only make it a json array instead of a new string format which need to be parsed.
What do you think about them?
Great feedback, keep it coming! :) regards, Ralf