Changes between Version 7 and Version 8 of DeprecatingFeatures

Timestamp:

Sep 21, 2012 3:39:56 PM (12 years ago)

Author:

abarth@webkit.org

Comment:

--

DeprecatingFeatures

@@ -11 +11 @@
  * ''Interoperability.''  If a feature fails to garner wide-spread implementation, then web sites that use that feature might work in one user agent but not in another.  This lack of interoperability fractures the web platform, making it more difficult for users to switch from one user agent to another.  Removing WebKit-proprietary features, or at least hiding them from the web platform, often improves interoperability.
 
- * ''Complexity.''  Each feature we include in WebKit increases WebKit's complexity, slowing down development of the engine.  We try to reduce the complexity cost of features, for example by using [[Modules]], but each feature still adds a non-zero cost (e.g., for project-wide improvements, like [[EfficientStrings]]).  Removing some features (e.g., Workers) reduces the complexity of WebKit greatly, whereas removing others (e.g., Blob.webkitSlice) has little impact on WebKit's overall complexity.
+ * ''Complexity.''  Each feature we include in WebKit increases WebKit's complexity, slowing down development of the engine.  We try to reduce the complexity cost of features, for example by using [[Modules]], but each feature still adds a non-zero cost (e.g., for project-wide improvements, like [[EfficientStrings]]).  Removing some features (e.g., Workers) would reduce the complexity of WebKit greatly, whereas removing others (e.g., Blob.webkitSlice) would have little impact on WebKit's overall complexity.
 
 = Approaches for removing features =
@@ -25 +25 @@
 == A port-specific experiment ==
 
+A more controlled approach to removing a feature is to remove the feature from a single port as an experiment.  In this approach, one port removes the feature (e.g., via an ENABLE macro or a run-time setting) and gathers feedback from its release cycle.  If the port succeeds in removing the feature, we can then remove the feature from the remaining ports with greater confidence that they will also avoid problems.
 
+This approach as two main benefits:
+
+ 1. The risks associated with removing a feature are concentrated on a single port.  If you're passionate about removing a feature, you might have more luck convincing one port to experiment with removing a feature than convincing all the ports at once.  That port can bear the risks and the project as a whole can learn about the costs of removing the feature.
+
+ 2. Actually removing a feature is the only way to really know what problems will arise when you remove a feature.  We can estimate the risks by searching for uses of a feature or by measuring how often a feature is used, but those are only estimates.  For example, many web sites detect which features are enabled and then take different code paths depending on what they're able to detect, adding noise both to code searches and to runtime measurements.
 
 == Measure, deprecate, and remove ==