[webkit-dev] Runtime setting for incomplete features

[Darin Fisher]

On Mon, Oct 5, 2009 at 9:45 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:
>
> On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
>>
>>
>>
>> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson <atwilson at google.com> wrote:
>>
>>  I'm surprised to see these objections coming up now, weeks after the
>>> original discussion, and only after my patch has landed in the tree.
>>>
>>
>> Sorry, I seemed to have missed that thread. I did however file a bug as
>> soon as the first runtime switch went in.
>>
>>
>>> That said, I agree that in an ideal world, we'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't a hugely important issue, since these features are
>>> only runtime-disabled while under development and so not widely available
>>> anyway.
>>>
>>
>> I obviously disagree with Maciej on this. I think it is bad to break
>> developers expectations for feature detection.
>>
>>
>> My comments were specifically based on the Chrome team's plans to only
>> have the runtime switch in "dev channel" builds, and always fully compile
>> features out in release product.
>>
>
> That'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.
>
>
> Jeremy Orlow said said (in an earlier email):
>
> "I'm also going to send mail to chromium-dev proposing that we never ship
> anything but a "dev channel" browser with such experimental features
> compiled in for the reasons we've discussed here."
>
> 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.
>
>
Yes, it was rejected.



> 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.
>
>
> I'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?
>
>
It is a matter of our process that we do not change the configuration when
promoting builds.  The bits that passed the test get promoted.

I'm happy to absorb this cost in the V8 bindings.  I don't think it is
important to solve this problem for the JSC bindings since there is not a
consumer that yet needs the same.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091005/4f6d5536/attachment.html>