<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 12, 2013 at 3:17 PM, Mike Perez <span dir="ltr"><<a href="mailto:thingee@gmail.com" target="_blank">thingee@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div>On 10:06 Thu 12 Dec     , Christopher Yeoh wrote:</div><div>> On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann</div>
<div>> <<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>>wrote:</div>> <div>> So for compatibility testing I think what will probably happen is that</div><div>> we'll be defining a minimum set (API_V3_CORE_EXTENSIONS)</div>


<div>> that must be implemented and clients can rely on that always being present</div><div>> on a compliant cloud. But clients can also then query through /extensions</div><div>> what other functionality (which is backwards compatible with respect to</div>


<div>> core) may also be present on that specific cloud.</div><br></div></div><div>I'm worried by the discrepancies this will create among the programs. You</div>

<div>mentioned maintainability being a plus for this. I don't think it'll be great</div><div>from the deployers perspective when you have one program that thinks everything</div><div>is an extension and some of them have to be enabled that the deployer has to be</div>


<div>mindful of, while the rest of the programs consider all extensions to be</div><div></div></div></blockquote><div><br></div><div>Just to be clear, the deployer doesn't have to enable these, they are enabled automatically,<br>
but it will complain if a deployer attempts to disable them. Also anything not core has a<br></div><div>"os-" prefix, while core plugins don't so it is easy to distinguish between them. But yes I'd agree<br>
that from a deployers point of view its not useful to talk about extensions which have<br>to be enabled.<br></div><div> <br></div><div>Chris<br></div></div></div></div>