[webkit-dev] Runtime setting for incomplete features

[Drew Wilson]

On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig <sam.weinig at gmail.com> 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.
>
>
OK, it's good to get consensus, even if it comes after I already thought we
had achieved it :)

>From a purist's perspective, I see where you're coming from. Pragmatically,
though, these runtime flags are only available on the Chrome dev channel
(and go away before the features are ever shipped to the beta/stable
channels) so the compatibility issues are somewhat moot. We've discussed
removing these feature flags (and the ability to disable the features at
runtime) once the features become stable - I don't know if that's a good
idea or not, but that might impact this discussion as well.


>
>> Regardless, I don't think we should rush out to roll all of those features
>> out of the tree, and I certainly don't think we should be singling out
>> SharedWorkers or WebSockets
>>
>
> I don't mean to single out SharedWorkers or WebSockets, but I don't see any
> others using the same technique (barring window.Audio, which I don't think
> is the same thing, but should non-the less be fixed).  But, as we have many
> developers using the nightlies, I think this should be handled with some
> speed.
>

Take a look at DOMWindow.cpp - there's quite a bit of code that does
something like "look at settings to see if feature is enabled, return null
if not" (DOMWindow::openDatabase(), for an example).

We discussed changing this code to return undefined instead of null, which
was the genesis of this thread, before we realized that the issues ran
deeper than that.


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