[webkit-dev] Runtime setting for incomplete features

[Maciej Stachowiak]

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.

> 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?

Regards,
Maciej

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