On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:
On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak <[email protected]>
wrote:
On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson <[email protected]>
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.
My comments were specifically based on the Chrome team's plans to
only have the runtime switch in "dev channel" builds, and always
fully compile features out in release product.
That's not how we do things. Sorry for the confusion. What ships
in dev channel goes to beta provided it passes the quality metrics.
What ships in beta goes to stable again provided it passes the
quality metrics. We do not change the build configuration when
promoting a build.
Jeremy Orlow said said (in an earlier email):
"I'm also going to send mail to chromium-dev proposing that we never
ship anything but a "dev channel" browser with such experimental
features compiled in for the reasons we've discussed here."
Others seemed to agree with that line of thinking. If his suggestion
was rejected, then yes, we should go back to the drawing board.
Shipping partly-detectable but disabled features in production builds
would be bad.
Therefore, it is essential that feature detection is done correctly
even in dev channel builds. My apologies if you have received mixed
messages on this.
I'm concerned that the cost in code complexity for enabling runtime
switching with perfect detectability properties may be high. The
drivers for that cost seem (at first glance) like inessential aspects
of the Chromium development process. Is there any fundamental reason
that production builds have to ship with runtime-switchable
experimental features?
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
