[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
platform.
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.
Regards,
Maciej
-------------- 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