incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "marios@redhat.com" <mandr...@redhat.com>
Subject Re: Sketch of CIMI model layer
Date Thu, 03 Nov 2011 09:46:53 GMT
On 03/11/11 01:08, lutter@redhat.com wrote:
> This patch is a first attempt at a CIMI model layer. Such a layer is needed
> to deal with deserialization (and possibly serialization) of CIMI model
> objects from (to) XML/JSON, and to give us a place to stash business logic
> connected to model classes.
> 
> This patch is solely for discussion, it most definitely will not work; at a
> minimum there are various 'require' that are missing.
> 
> There's two things that make such a model layer interesting:
> 
>   * The need to deal with differences between the JSON and XML
>     representation; I believe they are all mechanical, though the CIMI
>     draft does not set out any explicit rules. The main rule is that an
>     array of things in JSON is represented as { 'things': [ .. array .. ] }
>     whereas the XML uses a sequence of <thing/> elements

I recall discussion a while back about whether we need to include
wrappers for 'array' elements in the xml serialization... i.e.

<volumes>
	<volume href="xs:anyURI"
          attachmentPoint="xs:string" protocol="xs:string" />
	<volume href="xs:anyURI"
          attachmentPoint="xs:string" protocol="xs:string" />
<volumes/>

(not sure but may have been in relation to mantis #1195). I wonder
whether this needs to be revisited if it will help to bridge the
difference between json+xml 'arrays' and help with our deserialization.
The spec doees currently include 'cardinality characters' after items to
indicate:

"?" (0 or 1)
"*" (0 or more)
"+" (1 or more)

e.g. the xml serialization of the volume attribute for machine template:

 <volume href="xs:anyURI"
          attachmentPoint="xs:string" protocol="xs:string" /> *

but I don't think that's enough metadata to help us; it does tell us
that there may be more of this <thing> but we still need to search
through the xml doc to find all occurrences.


>   * see if we can really have a Base.to_xml; the two big issues to settle
>     are
>       (1) indicate which attributes go into XML attributes and which ones
>           go into elements, e.g.
>             ref :foo, :xml_attr => true

we could in theory maintain the list of 'entities' though we would need
to maintain and update it with the spec... - machine, machine template,
volume, network, job, meter etc ... any <thing> that's not an entity is
by default an xml attribute. Having said that, the spec does include
extensibility mechanisms whereby cloud providers can extend the model by
defining new resource types, though these are advertised with
'EntityMetadata' resource (but this last point is a recommendation only).

> 
>       (2) for attributes that are not scalars, do (1) recursively; in
>           particular, allow associating a class with the members of an
>           array
> 
>             array :things, :class => Thing
> 
>           where Thing itself is a subclass of Base
> 
>   * some type specific validation (a 'ref' should look like a URI, we could
>     add types to 'scalar' and make sure integers look like integers etc.)
> 
>   * a unit test or two
> 
> Another sidenote: since the CIMI API isn't terribly HTML friendly (e.g.,
> POST's all have XML or JSON bodies), I wonder if the HTML frontend
> shouldn't be a JS app that communicates with the server via JSON only.
> 
> David


Mime
View raw message