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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
