On Mon, Oct 5, 2009 at 9:45 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="word-wrap:break-word"><br><div><div><div></div><div class="h5"><div>On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div style="word-wrap:break-word"><br><div><div><div>On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:</div><br><blockquote type="cite">

<br><br><div class="gmail_quote">On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson <span dir="ltr">&lt;<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>&gt;</span> wrote:</div> <div class="gmail_quote">

<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div> I&#39;m surprised to see these objections coming up now, weeks after the original discussion, and only after my patch has landed in the tree. </div>

 </span></div></blockquote><div><br></div><div>Sorry, I seemed to have missed that thread. I did however file a bug as soon as the first runtime switch went in.</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

 <div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>That said, I agree that in an ideal world, we&#39;d hide window.audio, shared workers, notifications, local storage, databases, session storage and any other runtime/platform-disabled API from enumerations - I just agree with Maciej that this isn&#39;t a hugely important issue, since these features are only runtime-disabled while under development and so not widely available anyway.</div>

 </span></div></blockquote><div><br></div><div>I obviously disagree with Maciej on this. I think it is bad to break developers expectations for feature detection.</div></div></blockquote><div><br></div></div><div>My comments were specifically based on the Chrome team&#39;s plans to only have the runtime switch in &quot;dev channel&quot; builds, and always fully compile features out in release product.</div>

 </div></div></blockquote><div><br></div><div>That&#39;s not how we do things.  Sorry for the confusion.  What ships in dev channel goes to beta provided it passes the quality metrics.  What ships in beta goes to stable again provided it passes the quality metrics.  We do not change the build configuration when promoting a build.</div>

</div></blockquote><div><br></div></div></div><div>Jeremy Orlow said said (in an earlier email):</div><div><br></div><div><div class="im"><div>&quot;I&#39;m also going to send mail to chromium-dev proposing that we never ship anything but a &quot;dev channel&quot; browser with such experimental features compiled in for the reasons we&#39;ve discussed here.&quot;</div>

</div></div></div></div></blockquote><div><br></div><div>I did, and Darin rejected it.  :-)</div><div><br></div><div>I guess we should have brought the discussion back here after we talked about the Chromium half of that.  Sorry.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div><div>Others seemed to agree with that line of thinking. If his suggestion was rejected, then yes, we should go back to the drawing board. Shipping partly-detectable but disabled features in production builds would be bad.</div>

</div><div class="im"><br><blockquote type="cite"><div class="gmail_quote"> <div>Therefore, it is essential that feature detection is done correctly even in dev channel builds.  My apologies if you have received mixed messages on this.</div>

</div></blockquote><br></div></div><div>I&#39;m concerned that the cost in code complexity for enabling runtime switching with perfect detectability properties may be high. The drivers for that cost seem (at first glance) like inessential aspects of the Chromium development process. Is there any fundamental reason that production builds have to ship with runtime-switchable experimental features?</div>

<div><br></div><div>Regards,</div><div>Maciej</div><font color="#888888"><div><br></div></font></div><br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
<br></blockquote></div><br>