<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If EC2 API is limiting what we can do, that's not going to change just<br>

because you move the EC2 API implementation into a proxy in front of the<br>
OpenStack API. The only difference is that it's suddenly the AWSOME<br>
development team's problem.<br></blockquote><div><br></div><div>I think it's actually the EC2 API caller's problem.  It's easy to map a subset to a superset, but you can't cover the superset with the subset.  Suppose Quantum defines e.g. Layer 2 security groups, which I think has no parallel in EC2.  If you want to use L2 security groups, you'd have to use the OpenStack API.</div>
<div><br></div><div>A nice AWSOME developer might treat it as their problem, but it's not really.</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">> With one native API, we can focus all our energies on making sure that API<br>
> works.  Then, knowing that the native API works, we can build other APIs on<br>
> top through simple translation layers, and they will work also.  Other APIs<br>
> can be built on top in the same way (e.g. OCCI)<br>
<br>
</div>Sorry, I'm having trouble here.. Are you suggesting that having two<br>
sibling frontend API's talking to a shared backend API is poor software<br>
engineering, but layering similar purposed API's on top of each other<br>
like this is good software engineering?</blockquote><div><br></div><div>Obviously not when you put it like that :-)</div><div><br></div><div>The difference that I see is whether the 'service' layer is documented and kept stable (i.e. subject to API evolution rules).  Right now, we do that work for the OpenStack API only.</div>
<div><br></div><div>I think it's great if someone is going to document and stabilize our internal APIs.  However, unless you're willing to do it personally, I don't think anyone should assume it'll be done.</div>
<div><br></div><div>So my viewpoint is that, while it would be great to have interface contracts on all our internal interfaces, I'll believe it when I see it.  Until then, we have one stable interface, and so using that stable interface as the service layer seems like a sensible approach.</div>
<div><br></div><div>I can see us using ProtocolBuffers or JSON schema for messages that go over the message bus, maybe even in Folsom.  I can't see us locking down the other code interfaces before we give up on this Python thing and port to Java, i.e. it's not going to happen.</div>
<div><br></div><div>Actually, I think JSON schema for our message-bus messages might be a really good idea (tm).  Violations could just be warnings until we get things locked down... maybe I should propose a blueprint? (Although I have enough of a blueprint backlog as it is...)</div>
<div><br></div><div>Justin</div><div><br></div></div></div>