<div dir="ltr">Hi John,<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 7:26 AM, John Dewey <span dir="ltr"><<a href="mailto:john@dewey.ws" target="_blank">john@dewey.ws</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div>
                    I have a similar concern.  The underlying driver may support different functionality, but the differentiators need exposed through the top level API.</div></blockquote><div>Not really, whole point of the service is to abstract the user from specifics of backend implementation. So for any feature there is a common API, not specific to any implementation.</div>
<div><br></div><div>There probably could be some exception to this guide line that lays in the area of admin API, but that's yet to be discussed.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>I see the SSL work is well underway, and I am in the process of defining L7 scripting requirements.  However, I will definitely need L7 scripting prior to the API being defined.</div><div>Is this where vendor extensions come into play?  I kinda like the route the Ironic guy safe taking with a “vendor passthru” API. </div>
</blockquote><div>I may say that core team has rejected 'vendor extensions' idea due to potential non-uniform user API experience. That becomes even worse with flavors introduced, because users don't know what vendor is backing up the service they have created.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div></div><br></div></div>