[webkit-dev] Runtime setting for incomplete features

Maciej Stachowiak mjs at apple.com
Tue Oct 6 00:39:19 PDT 2009

On Oct 5, 2009, at 10:08 PM, Fumitoshi Ukai (鵜飼文敏) wrote:

> So, is it fine to make WebSockets enable by default?
> For now, there are no SocketStreamHandle implementation. so even  
> enabling WebSockets in Settings, it is the almost same that the  
> feature is not available..

As far as I'm concerned, that's ok for testing, even though we would  
not want to ship that way. If the state is so bad that we don't even  
want people testing, then the feature should be compiled out entirely.  
In my opinion, anyway.

  - Maciej

> -- 
> ukai
> On Tue, Oct 6, 2009 at 2:04 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
> On Oct 5, 2009, at 9:54 PM, Mark Rowe wrote:
>> On 2009-10-05, at 21:48, Darin Fisher wrote:
>>> It is a matter of our process that we do not change the  
>>> configuration when promoting builds.  The bits that passed the  
>>> test get promoted.
>>> I'm happy to absorb this cost in the V8 bindings.  I don't think  
>>> it is important to solve this problem for the JSC bindings since  
>>> there is not a consumer that yet needs the same.
>> The present state of Web Sockets is that they're compiled in on Mac  
>> OS X but disabled via the runtime setting.  This leads to them  
>> being detectable in the manner Sam mentioned.  Either the compile- 
>> time setting needs to be fixed for Mac OS X or the runtime code  
>> fixed so that the feature is not detectable when disabled.  I  
>> assume that we want regression testing of the feature so disabling  
>> it at compile time does not seem like the best idea.  I guess it  
>> comes down to whether or not it's in good enough shape to be useful  
>> to web sites at this time.
> I think WebSockets should be compiled in and enabled on Mac OS X. I  
> don't think we even need a way to turn them off at runtime for non- 
> Chromium ports. The policy we generally follow for nightly builds is  
> that we enable new features unless they would create significant  
> problems with normal browsing, or major security risk, for users of  
> the nightlies. We do sometimes disable optional features shortly  
> before branching WebKit for release (apparently unlike the Chromium  
> process) and I don't believe we've ever had a bug caused by that. We  
> certainly wouldn't ship a production build of WebKit on Mac OS X  
> with a feature compiled in but disabled at runtime.
> Regards,
> Maciej
> _______________________________________________
> 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/20091006/5df1ffb6/attachment.html>

More information about the webkit-dev mailing list