
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">

<div><br>

</div>

<div><br>

</div>

<br>

<div>

<div>On Dec 19, 2012, at 2:29 PM, Matt Dietz wrote:</div>

<br class="Apple-interchange-newline">

<blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">As

 to the last point, I feel like I'm missing something. How are they core<br>

API if they're still modular/optional? What I think the argument has<br>

boiled down to here is consistent user experience, which to me means that<br>

everyone at the very least should be prepared to run the Core API and all<br>

that it entails. If you aren't capable or unwilling to support it, that's<br>

no better than a random selection of extensions being being made<br>

available. Being able to selectively choose but still be "core" doesn't<br>

sound like it solves anything as far as I'm concerned.</span></blockquote>

</div>

<br>

<div><br>

</div>

<div>Totally agree with Matt on this point.  Whatever we decide is core should be supported by all implementations / deployments. We should consider that when we decide what to promote to core.</div>

<div><br>

</div>

<div>-jOrGe W.</div>

<div><br>

</div>

</body>

</html>