[webkit-dev] Runtime setting for incomplete features

Maciej Stachowiak mjs at apple.com
Wed Sep 23 18:03:28 PDT 2009

On Sep 23, 2009, at 5:24 PM, Drew Wilson wrote:

> Following up on this, because I missed Maciej's response.
> On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
> Fair enough. But I would be against user-level preferences that add  
> or remove entire APIs. Rather, the preference should affect the  
> behavior of the API (possibly making it do nothing). So far the only  
> actual user-level preference I'm aware of that effectively disables  
> APIs is private browsing. And I think the way it works (in both  
> Safari and Chrome, even though it is different) is better than it  
> would be to make storage-related APIs disappear completely.
> Maciej, are you saying that if I were to add a flag to disable  
> SharedWorkers, you'd want it to leave the constructor intact (i.e.  
> not remove the API) but just not create the actual thread?

Do you think such a flag would make sense as an end-user preference,  
as opposed to a command-line experimental feature switch?

> That seems bad, as it means web apps can't do capability checking.  
> It seems better to remove the API. I'm about to add a flag for  
> SharedWorkers (possibly just within Chromium if I can), so I  
> definitely want to resolve this.

Are you planning to expose this as a user-visible preference?

My thinking on the topic is basically this:
A) For experimental features, it makes sense to make them disappear  
completely when turned off, since turning them on is an unusual and  
experimental state.
B) For end-user features that are on by default but have a preference  
to turn them off, having APIs appear and disappear fragments the  

I think B implies that most APIs shouldn't be direct line items in  
preferences to end users in a production version, more so than  
implying a particular strategy. For experimental features, making the  
API disappear seems fine and perhaps even desirable.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090923/25e097b7/attachment.html>

More information about the webkit-dev mailing list