<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 14, 2014 at 8:06 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 01/14/2014 05:17 AM, Christopher Yeoh wrote:<br>
> On Mon, Jan 13, 2014 at 10:38 PM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a><br>
</div><div><div class="h5"><br>
</div></div>This skirts the run time issue, but using twice as many resources. It<br>
doesn't however address the fact that real effort goes into maintaining<br>
and reviewing those clients. Or the review on the Nova side to get these<br>
things in. Or the double documentation duties. Or the fact that it<br>
inhibits certain things in JSON because they wouldn't be XML friendly.<br>
Or the extra code that we need to carry around to handle bad XML insertion.<br>
<br>
There is a real cost of our dual data payload strategy. A cost in real<br>
people that means we aren't doing other things, or doing other things<br>
better.<br>
<br>
The folks working on keeping XML alive aren't doing it because they have<br>
a dramatic passion for XML and wouldn't be contributing to the project<br>
otherwise, so I think we'd be able to cover far more important parts of<br>
the project if we dropped this load.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Oh I totally agree with this, was just thinking of alternatives if we can't get consensus as I know this has been suggested before that we should remove the XML support.<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
>     I think it would be a much better situation if the Nova API is a<br>
>     single payload type. The work on the jsonschema validation is also<br>
>     something where I think we could get to a fully discoverable API,<br>
>     which would be huge.<br>
><br>
><br>
> Discoverable is nice to a point but I think we need to be cautious how<br>
> far we take it as I think at least the positive tests should be written<br>
> based on the specification and not autogenerated because that will help<br>
> pick up inconsistencies we have between what we claim our API is versus<br>
> what it actually is (more automation of documentation will help reduce<br>
> but I don't think it will eliminate that problem).<br>
<br>
</div>I don't want discoverability for Tempest (not on the positive side), I<br>
100% believe that we should remain explicit on function testing.<br>
<br>
I want discoverability for Users and SDKs. I want user toolkits that<br>
work with Nova to have a fully discoverable way to work with our API. As<br>
I think that would be a *great* API for our users, and would make life<br>
dramatically simpler for our SDK ecosystem.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>+1 <br></div><br></div><div class="gmail_quote">And as I mentioned in another thread having a summit cross project session on APIs I think<br>
would be very valuable and should cover these sorts of issues.<br><br></div><div class="gmail_quote">Chris<br></div><div class="gmail_quote"><br></div></div></div>