On Feb 27, 2014, at 7:23 AM, Doug Hellmann 
<<>> wrote:

On Thu, Feb 27, 2014 at 2:00 AM, Noorul Islam K M 
<<>> wrote:
Michael Davies <<>> writes:

> Hi everyone,
> Over in "Ironic Land" we're looking at removing XML support from ironic-api
> (i.e.
> I've been looking, but I can't seem to find an easy way to modify the
> accepted content_types.
> Are there any wsgi / WSME / Pecan experts out there who can point me in the
> right direction?

Also in Solum we have a use case where in we would like to have
pecan+wsme accept content-type application/x-yaml.

It will be great if this can be made configurable.
What do you want to have happen with the YAML?

We want to parse it into a graph of objects. It will be similar in nature to 
processing a Heat template. We will treat the resulting data structure as a 
model for generation of Heat templates, after some logic is applied to each 
object in the graph, and the relations between them.

Do you want to receive and return YAML to a bunch of API calls? We could add 
YAML protocol support to WSME to make that happen.

We might have a total of 3 API calls that take application/x-yaml as inputs in 
addition to the same calls also accepting application/json.

Do you want a couple of controller methods to be given a YAML parse result, 
rather than WSME objects? You could write an expose() decorator for Pecan in 
Solum. This would be a more appropriate approach if you just have one or two 
methods of the API that need YAML support.

Interesting. Can you think of existing implementations we could reference that 
are using this approach? What would you consider the pro/con balance for this?

Or do you want the YAML text passed in to you directly, maybe to be uploaded in 
a single controller method? You should be able to have that by skipping WSME 
and just using Pecan's expose() decorator with an appropriate content type, 
then parsing the body yourself.

We probably don't need to do our own parsing of the YAML text, as we expect 
that to be regular YAML. We probably don't need to parse it incrementally as a 
stream because even our most complex YAML content is not likely to be more than 
a few hundred nodes, and should fit into memory. We do, however need to be able 
to inspect and walk through a resulting data structure that represents the YAML 

Would it be sensible to to have a translation shim of some sort that interprets 
the YAML into JSON, and feeds that into the existing code so that we would be 
confident there was no difference between parsing the YAML versus parsing 
equivalent JSON?





OpenStack-dev mailing list<>

OpenStack-dev mailing list<>

OpenStack-dev mailing list

Reply via email to