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 <[email protected]>
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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
