[webkit-dev] Runtime setting for incomplete features

[Sam Weinig]

I don't think I wrote the Audio code, (I think I probably just moved it),
but I also don't believe it is intended as a general purpose runtime switch
(but rather fallback when there are no installed codecs).  It is also not
something people are going to ship as far as I can tell, and is therefore a
much smaller compatibility risk.

-Sam

On Mon, Oct 5, 2009 at 5:54 PM, Drew Wilson <atwilson at google.com> wrote:

> BTW, I modeled my SharedWorker disabling after the code in
> JSDOMWindowCustom::audio() that disables the audio constructor on platforms
> that don't have MediaPlayer support.
> I think the runtime behavior of window.audio and window.SharedWorker should
> be identical in practice. Sam, it looks like you wrote
> JSDOMWindowCustom::audio() - do you see its behavior as unacceptable as
> well, or do you have some other code to prevent enumeration of window.audio
> that I can generalize for use for SharedWorkers too?
> -atw
>
>
> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson <atwilson at google.com> wrote:
>
>> So, two weeks ago I sent an email on this thread stating exactly what I
>> was planning to do, To whit:
>> >>>
>>  I do think that we ought to be returning undefined instead of null in
>> those cases, though, just to catch people who are accidentally using
>> isUndefined() utility functions from common libraries. It would not be hard
>> to define some kind of [mapNullToUndefined] custom attribute for the code
>> generator.
>> <<<
>>
>> Maciej and AP both chimed in saying that disabling enumeration (i.e.
>> "SharedWorker in window") would be prohibitively hard, and giving a tacit OK
>> to my approach (my emphasis below):
>>
>> >>>
>> It would be pretty complicated to do that [disabling [LocalStorage in
>> window"] based on a runtime setting. You would need a custom getter for any
>> object that has properties which may appear or disappear based on settings.
>> This is *probably too complicated to be worth it*. Or at least, if we
>> added that level of code complexity I would begin to doubt the merits of
>> supporting runtime enabling of Web platform features.
>> <<<
>>
>> 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. 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.
>>
>> 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 - if we feel strongly that this needs to be
>> addressed, we can update all of those features accordingly. If people with
>> knowledge of the internals of V8 and JSC can chime in, we can discuss how
>> best to approach this.
>>
>> -atw
>>
>>
>> On Mon, Oct 5, 2009 at 5:04 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
>>
>>> Hi Folks,
>>>
>>> I am not happy with the way these runtime settings have been implemented
>>> so far as they break runtime detection using the technique we evangelize to
>>> developers, specifically, using the ("property" in window) method.  A
>>> feature that is turned off at runtime should not be detectable at all, using
>>> any method (including Object.keys(), object.hasOwnProperty(),
>>> object.propertyIsEnumerable(), for-in enumeration, etc).  I filed
>>> https://bugs.webkit.org/show_bug.cgi?id=29896 when the WebSocket runtime
>>> switching code went in and was disappointed to see similarly buggy code go
>>> in for SharedWorkers with out this being fixed.
>>> Leaving this in the tree is likely to introduce compatibility issues so I
>>> would recommend that we roll out these changes if they cannot be fixed in a
>>> timely manner.
>>>
>>> -Sam
>>>
>>> On Tue, Sep 8, 2009 at 11:47 PM, Darin Fisher <darin at chromium.org>wrote:
>>>
>>>> As is described in https://bugs.webkit.org/show_bug.cgi?id=28941, for
>>>> the Chromium project, we like to make incomplete features available
>>>> behind a command line flag to help facilitate testing.  I understand
>>>> that the norm for WebKit is to only have compile time options for new
>>>> / incomplete features.  In some cases, runtime settings are defined,
>>>> but these generally correspond to end user preferences or the needs of
>>>> specific embedders.
>>>>
>>>> At any rate, I just wanted to make sure that folks were aware that
>>>> some settings may only exist to help facilitate Chromium's goal of
>>>> shipping incomplete features, disabled by default.
>>>>
>>>> Alexey asked if there are any guidelines for when these settings may
>>>> be removed.  I think the main thing is that the feature has to be
>>>> reasonably complete and enabled by default by embedders (e.g.,
>>>> Chromium) that are compiling the feature.
>>>>
>>>> Regards,
>>>> -Darin
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091005/05a3f34b/attachment.html>