Intent to Ship: Experimental Framework
Owen
Contact emails
cha...@chromium.org, owe...@chromium.org
Mailing list: experimen...@chromium.org
Spec
https://github.com/jpchase/ExperimentalFramework/blob/master/explainer.md
Summary
In response to Alex Russell’s post Doing Science on the Web we have designed the Experimental Framework to improve the API quality of new features by allowing browser engineers to obtain feedback from developers on new features prior to completing standardization. Specifically, the framework allows web developers to opt origins they control into an “origin trial” being run for an experimental feature. The trial will then allow the web developer to try the new feature in production and provide feedback to browser engineers.
Developers will need to register for a token which provides access to the experimental features and commit to providing feedback. The full system that enables registration is not yet ready to ship. When complete, we expect developers will be able to sign up in a similar way to the way the Chrome Web Store works for extensions and app developers today. For now, developers that wish to try an experimental feature will need to fill out a Google form that will be included in the Intent to Experiment template.
We have designed an addition to the Blink Intent process to accommodate the launch of new experimental features, which was positively discussed at an API owners meeting on 02/16/16. The new process will be incorporated into the main Blink Process guide after this Intent to Ship is approved, and we will be carefully monitoring the first few launches to ensure the right amount of process is in place.
We have created a guide for browser engineers seeking to ship a feature with the Experimental Framework.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/GsPtuFt8XqA/ks5Dz5vdBwAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Windows, Mac, Linux, ChromeOS, Android: Yes
Android WebView: No, since WebView lacks necessary infrastructure for running origin trials such as Finch and UMA.
Debuggability
There are currently no specific additions or changes to DevTools, but we’ll be listening to developer feedback and expect to make additions in the future, for example listing all the features enabled for a page or a tool to validate a given token, etc.
Interoperability and Compatibility Risk
From a web-facing API perspective, there is low risk, as very little of the framework itself is exposed to web developers. Specifically, the only impact is the addition of an <meta name="origin-trials"> tag to provide a trial token to the browser which will enable features for specific origins. The meta tag format is intentionally not yet standardized - as each meta tag is only valid for the duration of one origin trial, we are able to change the format over time, and plan to ensure our current design works well for the first few features before standardizing it. Note we’ve submitted a request to list this new meta tag on the whatwg wiki.
A specific goal of the Framework is to ensure that long-term compatibility risk for new features is reduced. Additionally, we will monitor the use of each feature with RAPPOR, and disable any features that reach usage levels which would prevent them from being withdrawn from the platform.
OWP launch tracking bug
https://code.google.com/p/chromium/issues/detail?id=538593
Entry on the feature dashboard
https://www.chromestatus.com/features/6331324939894784
Rick Byers
Elliott Sprehn
Jeremy Roman
Is there a C++ guide here somewhere? I'm looking at the docs, and it's not clear how you annotate an idl file, or where the bindings get injected...
Kentaro Hara
On Fri, Feb 19, 2016 at 8:11 PM, Elliott Sprehn <esp...@chromium.org> wrote:Is there a C++ guide here somewhere? I'm looking at the docs, and it's not clear how you annotate an idl file, or where the bindings get injected...Maybe it was added since you asked, but there are such instructions the in "guide for browser engineers" linked in the original email, which says:Practically, this means that you will have access to a boolean test "OriginTrials::myFeatureEnabled()" that you can call in Blink code at runtime to expose your feature. There is also an IDL attribute (currently 'APIExperimentEnabled', but subject to rename) that you can use to automatically expose and hide JavaScript objects.
PhistucK
--
You received this message because you are subscribed to the Google Groups "experimentation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to experimentation...@chromium.org.
To post to this group, send email to experimen...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/experimentation-dev/CABg10jwqbonbDgZgE1ykzaFffKpdMYURTxFD-n_%2Bj3SanPVnYw%40mail.gmail.com.
Jochen Eisinger
Jason Chase
On Saturday, February 20, 2016 at 6:30:30 AM UTC-5, PhistucK wrote:
This sounds like a pretty safe mechanism. Even if libraries end up feature detecting an API in trial, this does not make its usage rise (everyone must opt into it in order to make it even exist, so the use counter would be unaffected and feature detection is the right way to use anything anyway).I understand that there are talks about letting developers opt into a trial using an HTTP response header.If this is the plan (and it makes sense to go this way, in my opinion), it should be <meta http-equiv> and not <meta name>.
☆PhistucK
On Sat, Feb 20, 2016 at 9:59 AM, Kentaro Hara <har...@chromium.org> wrote:
On Sat, Feb 20, 2016 at 3:15 AM, Jeremy Roman <jbr...@chromium.org> wrote:On Fri, Feb 19, 2016 at 8:11 PM, Elliott Sprehn <esp...@chromium.org> wrote:Is there a C++ guide here somewhere? I'm looking at the docs, and it's not clear how you annotate an idl file, or where the bindings get injected...Maybe it was added since you asked, but there are such instructions the in "guide for browser engineers" linked in the original email, which says:Practically, this means that you will have access to a boolean test "OriginTrials::myFeatureEnabled()" that you can call in Blink code at runtime to expose your feature. There is also an IDL attribute (currently 'APIExperimentEnabled', but subject to rename) that you can use to automatically expose and hide JavaScript objects.It was already renamed to [OriginTrialEnabled].It would be helpful to add documentation to https://www.chromium.org/blink/webidl/blink-idl-extended-attributes .
On Fri, Feb 19, 2016 at 1:51 PM, Owen <owe...@chromium.org> wrote:
Contact emails
cha...@chromium.org, owe...@chromium.org
Mailing list: experimentation-dev@chromium.org
To unsubscribe from this group and stop receiving emails from it, send an email to experimentation-dev+unsub...@chromium.org.
To post to this group, send email to experimentation-dev@chromium.org.
Jason Chase
On Saturday, February 20, 2016 at 3:00:32 AM UTC-5, Kentaro Hara wrote:
On Sat, Feb 20, 2016 at 3:15 AM, Jeremy Roman <jbr...@chromium.org> wrote:On Fri, Feb 19, 2016 at 8:11 PM, Elliott Sprehn <esp...@chromium.org> wrote:Is there a C++ guide here somewhere? I'm looking at the docs, and it's not clear how you annotate an idl file, or where the bindings get injected...Maybe it was added since you asked, but there are such instructions the in "guide for browser engineers" linked in the original email, which says:Practically, this means that you will have access to a boolean test "OriginTrials::myFeatureEnabled()" that you can call in Blink code at runtime to expose your feature. There is also an IDL attribute (currently 'APIExperimentEnabled', but subject to rename) that you can use to automatically expose and hide JavaScript objects.It was already renamed to [OriginTrialEnabled].It would be helpful to add documentation to https://www.chromium.org/blink/webidl/blink-idl-extended-attributes .
On Fri, Feb 19, 2016 at 1:51 PM, Owen <owe...@chromium.org> wrote:
Contact emails
cha...@chromium.org, owe...@chromium.org
Mailing list: experimentation-dev@chromium.org
Spec
https://github.com/jpchase/ExperimentalFramework/blob/master/explainer.md
Summary
In response to Alex Russell’s post Doing Science on the Web we have designed the Experimental Framework to improve the API quality of new features by allowing browser engineers to obtain feedback from developers on new features prior to completing standardization. Specifically, the framework allows web developers to opt origins they control into an “origin trial” being run for an experimental feature. The trial will then allow the web developer to try the new feature in production and provide feedback to browser engineers.
Developers will need to register for a token which provides access to the experimental features and commit to providing feedback. The full system that enables registration is not yet ready to ship. When complete, we expect developers will be able to sign up in a similar way to the way the Chrome Web Store works for extensions and app developers today. For now, developers that wish to try an experimental feature will need to fill out a Google form that will be included in the Intent to Experiment template.
We have designed an addition to the Blink Intent process to accommodate the launch of new experimental features, which was positively discussed at an API owners meeting on 02/16/16. The new process will be incorporated into the main Blink Process guide after this Intent to Ship is approved, and we will be carefully monitoring the first few launches to ensure the right amount of process is in place.
We have created a guide for browser engineers seeking to ship a feature with the Experimental Framework.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/GsPtuFt8XqA/ks5Dz5vdBwAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Windows, Mac, Linux, ChromeOS, Android: Yes
Android WebView: No, since WebView lacks necessary infrastructure for running origin trials such as Finch and UMA.
Debuggability
There are currently no specific additions or changes to DevTools, but we’ll be listening to developer feedback and expect to make additions in the future, for example listing all the features enabled for a page or a tool to validate a given token, etc.
Interoperability and Compatibility Risk
From a web-facing API perspective, there is low risk, as very little of the framework itself is exposed to web developers. Specifically, the only impact is the addition of an <meta name="origin-trials"> tag to provide a trial token to the browser which will enable features for specific origins. The meta tag format is intentionally not yet standardized - as each meta tag is only valid for the duration of one origin trial, we are able to change the format over time, and plan to ensure our current design works well for the first few features before standardizing it. Note we’ve submitted a request to list this new meta tag on the whatwg wiki.
A specific goal of the Framework is to ensure that long-term compatibility risk for new features is reduced. Additionally, we will monitor the use of each feature with RAPPOR, and disable any features that reach usage levels which would prevent them from being withdrawn from the platform.
OWP launch tracking bug
https://code.google.com/p/chromium/issues/detail?id=538593
Entry on the feature dashboard
https://www.chromestatus.com/features/6331324939894784
Dimitri Glazkov
Chris Harrelson
LGTM2.--:DG<
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Jason Chase
On Monday, February 22, 2016 at 2:53:58 AM UTC-5, Jochen Eisinger wrote:
I think this framework will make it possible to ship new APIs with much more confidence.I'd like to hold off enabling the API, however, until the issues raised in the internal launch review are addressed.It's a bit unfortunate that the internal and external launch process aren't explicitly coupled, and I know that somebody is working on unifying those two.Usually, it would be fine to enable a new API or framework on trunk while the launch review is ongoing. In this case, however, blocking issues were raised, so I think it would be premature to enable the framework anyway, given that we now know of those issues.Can you please ping this thread again, once the issues were cleared, and you got the ok of the launch review team?best-jochen
On Sat, Feb 20, 2016 at 12:30 PM PhistucK <phis...@gmail.com> wrote:
This sounds like a pretty safe mechanism. Even if libraries end up feature detecting an API in trial, this does not make its usage rise (everyone must opt into it in order to make it even exist, so the use counter would be unaffected and feature detection is the right way to use anything anyway).I understand that there are talks about letting developers opt into a trial using an HTTP response header.If this is the plan (and it makes sense to go this way, in my opinion), it should be <meta http-equiv> and not <meta name>.☆PhistucKOn Sat, Feb 20, 2016 at 9:59 AM, Kentaro Hara <har...@chromium.org> wrote:
On Sat, Feb 20, 2016 at 3:15 AM, Jeremy Roman <jbr...@chromium.org> wrote:On Fri, Feb 19, 2016 at 8:11 PM, Elliott Sprehn <esp...@chromium.org> wrote:Is there a C++ guide here somewhere? I'm looking at the docs, and it's not clear how you annotate an idl file, or where the bindings get injected...Maybe it was added since you asked, but there are such instructions the in "guide for browser engineers" linked in the original email, which says:Practically, this means that you will have access to a boolean test "OriginTrials::myFeatureEnabled()" that you can call in Blink code at runtime to expose your feature. There is also an IDL attribute (currently 'APIExperimentEnabled', but subject to rename) that you can use to automatically expose and hide JavaScript objects.It was already renamed to [OriginTrialEnabled].It would be helpful to add documentation to https://www.chromium.org/blink/webidl/blink-idl-extended-attributes .
On Fri, Feb 19, 2016 at 1:51 PM, Owen <owe...@chromium.org> wrote:
Contact emails
cha...@chromium.org, owe...@chromium.org
Mailing list: experimentation-dev@chromium.org
To unsubscribe from this group and stop receiving emails from it, send an email to experimentation-dev+unsub...@chromium.org.
To post to this group, send email to experimentation-dev@chromium.org.