Re: [openstack-dev] WSME / Pecan and only supporting JSON?
On Thu, Feb 27, 2014 at 12:48 AM, Michael Davies mich...@the-davies.netwrote: Hi everyone, Over in Ironic Land we're looking at removing XML support from ironic-api (i.e. https://bugs.launchpad.net/ironic/+bug/1271317) 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? There's no support for turning off a protocol in WSME right now, but we could add that if we really need it. Why would we turn it off, though? The point of dropping XML support in some of the other projects is that they use toolkits that require extra work to support it (either coding or maintenance of code we've written elsewhere for OpenStack). WSME supports both protocols without the API developer having to do any extra work. Doug Thanks in advance, Michael... -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] WSME / Pecan and only supporting JSON?
Le 27/02/2014 14:13, Doug Hellmann a écrit : WSME supports both protocols without the API developer having to do any extra work. Doug Just one comment about WSGI middlewares that we could create for Pecan, we still need to handle both XML and JSON by hand. I do agree this is not WSME related, but that's still something which needs to be considered if needed. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] WSME / Pecan and only supporting JSON?
On Thu, Feb 27, 2014 at 2:00 AM, Noorul Islam K M noo...@noorul.com wrote: Michael Davies mich...@the-davies.net writes: Hi everyone, Over in Ironic Land we're looking at removing XML support from ironic-api (i.e. https://bugs.launchpad.net/ironic/+bug/1271317) 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? 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. 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. 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. Doug Regards, Noorul ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] WSME / Pecan and only supporting JSON?
On 02/27/2014 08:13 AM, Doug Hellmann wrote: On Thu, Feb 27, 2014 at 12:48 AM, Michael Davies mich...@the-davies.net mailto:mich...@the-davies.net wrote: Hi everyone, Over in Ironic Land we're looking at removing XML support from ironic-api (i.e. https://bugs.launchpad.net/ironic/+bug/1271317) 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? There's no support for turning off a protocol in WSME right now, but we could add that if we really need it. Why would we turn it off, though? The point of dropping XML support in some of the other projects is that they use toolkits that require extra work to support it (either coding or maintenance of code we've written elsewhere for OpenStack). WSME supports both protocols without the API developer having to do any extra work. Because if an interface is exported to the user, then it needs to be both Documented and Tested. So that's double the cost on the validation front, and the documentation front. Exporting an API isn't set and forget. Especially with the semantic differences between JSON and XML. And if someone doesn't feel the XML created by WSME is semantically useful enough to expose to their users, they shouldn't be forced to by the interface. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] WSME / Pecan and only supporting JSON?
On Thu, Feb 27, 2014 at 8:28 AM, Sean Dague s...@dague.net wrote: On 02/27/2014 08:13 AM, Doug Hellmann wrote: On Thu, Feb 27, 2014 at 12:48 AM, Michael Davies mich...@the-davies.net mailto:mich...@the-davies.net wrote: Hi everyone, Over in Ironic Land we're looking at removing XML support from ironic-api (i.e. https://bugs.launchpad.net/ironic/+bug/1271317) 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? There's no support for turning off a protocol in WSME right now, but we could add that if we really need it. Why would we turn it off, though? The point of dropping XML support in some of the other projects is that they use toolkits that require extra work to support it (either coding or maintenance of code we've written elsewhere for OpenStack). WSME supports both protocols without the API developer having to do any extra work. Because if an interface is exported to the user, then it needs to be both Documented and Tested. So that's double the cost on the validation front, and the documentation front. Exporting an API isn't set and forget. Especially with the semantic differences between JSON and XML. And if someone doesn't feel the XML created by WSME is semantically useful enough to expose to their users, they shouldn't be forced to by the interface. I guess I can see that. Bugs and blueprints can be filed at https://launchpad.net/wsme. It's not likely to happen in the next few weeks, but it shouldn't be difficult to provide some sort of switch to turn off XML support. Doug -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] WSME / Pecan and only supporting JSON?
Doug, On Feb 27, 2014, at 7:23 AM, Doug Hellmann doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote: On Thu, Feb 27, 2014 at 2:00 AM, Noorul Islam K M noo...@noorul.commailto:noo...@noorul.com wrote: Michael Davies mich...@the-davies.netmailto:mich...@the-davies.net writes: Hi everyone, Over in Ironic Land we're looking at removing XML support from ironic-api (i.e. https://bugs.launchpad.net/ironic/+bug/1271317) 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 content. 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? Thanks, Adrian Doug Regards, Noorul ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] WSME / Pecan and only supporting JSON?
On Thu, Feb 27, 2014 at 9:33 AM, Adrian Otto adrian.o...@rackspace.comwrote: Doug, On Feb 27, 2014, at 7:23 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Thu, Feb 27, 2014 at 2:00 AM, Noorul Islam K M noo...@noorul.comwrote: Michael Davies mich...@the-davies.net writes: Hi everyone, Over in Ironic Land we're looking at removing XML support from ironic-api (i.e. https://bugs.launchpad.net/ironic/+bug/1271317) 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? I'm not aware of any OpenStack APIs that take YAML input now, but that doesn't mean they don't exist. 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 content. 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? Is the same controller method taking both JSON and YAML at different times, like we support now with JSON and XML? I'm not sure I would convert YAML text to JSON text, but converting the YAML document to the same set of data structures represented by the JSON would make sense. For reference: This is the WSME decorator that handles converting incoming data to WSME objects: http://git.openstack.org/cgit/stackforge/wsme/tree/wsmeext/pecan.py#n46 If you want to add YAML support to WSME, you would need to add an appropriate call to the top like we have there for JSON and XML, and then implement a YAML protocol plugin under http://git.openstack.org/cgit/stackforge/wsme/tree/wsme/rest like you see there for JSON and XML. Doug Thanks, Adrian Doug Regards, Noorul ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] WSME / Pecan and only supporting JSON?
Hi everyone, Over in Ironic Land we're looking at removing XML support from ironic-api (i.e. https://bugs.launchpad.net/ironic/+bug/1271317) 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? Thanks in advance, Michael... -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] WSME / Pecan and only supporting JSON?
Michael Davies mich...@the-davies.net writes: Hi everyone, Over in Ironic Land we're looking at removing XML support from ironic-api (i.e. https://bugs.launchpad.net/ironic/+bug/1271317) 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. Regards, Noorul ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
