Intent to implement and ship: throttling requestAnimationFrame callbacks based on viewport visibility

[Sami Kyostila]

Contact emails

skyo...@chromium.org

Spec

This aspect of requestAnimationFrame is defined by the HTML processing model, but we have not proposed any spec changes yet. Design doc.

Summary

We want to stop running requestAnimationFrame callbacks for frames which aren't visible in the viewport. This helps to avoid unnecessary work for animations which aren't going to be seen by the user.

Motivation

The requestAnimation mechanism is a great way for pages to synchronize their animations with the display and the browser's own rendering. However, because there isn't an easy way to find out which parts of a page are visible, most pages end up perpetually subscribing to animation frame updates, causing unnecessary processing for animations which aren't even on the screen. A typical example is a long page with several ads (e.g., 500962, 447731, 395245, 515517, case study -- sorry, internal only, I'll see if we can make this public).

We think the long term solution to this problem is to bring better visibility and viewability APIs to the web. Because that will take some time and require content to be updated, this Intent proposes an optimization for today's web: if the browser can determine that the document which is being animated is invisible (e.g., its frame is outside the viewport bounds), the animation callbacks for that document won't be executed until the document becomes visible again.

Compatibility Risk

To minimize the compatibility risk with existing content, we are only planning to throttle requestAnimationFrame callbacks for documents in cross 

origin frames. Because cross origin frames can't synchronously interact with the outside world, there isn't a direct way to observe the exact timing of animation updates in the embedded document.

Note that pages already have to deal with requestAnimationFrame updates stopping completely when the tab is in the background.

Firefox: Shipped in Firefox 40 (however they throttle to 1 Hz instead of stopping completely and don't have the cross origin restriction.)

Internet Explorer: No public signals

Safari: No public signals

Web developers: No signals

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

None. (Implementation tracking bug: crbug.com/487937)

Link to entry on the feature dashboard

https://www.chromestatus.com/features/4514713492783104

Requesting approval to ship?

Yes.

[PhistucK]

On Mon, Aug 3, 2015 at 8:32 PM, Sami Kyostila <skyo...@chromium.org> wrote:

Firefox: Shipped in Firefox 40 (however they throttle to 1 Hz instead of stopping completely and don't have the cross origin restriction.)

​Currently in beta, not shipped as stable yet.​

☆PhistucK

[Rick Byers]

I'm excited to see this work going forward!  Reducing the performance impact of iframes is essential to Blink's top goals, so this is urgent.  However, it's not clear to me that this is ready to ship yet.  A few questions inline.

On Mon, Aug 3, 2015 at 1:32 PM, Sami Kyostila <skyo...@chromium.org> wrote:

Contact emails

skyo...@chromium.org

Spec

This aspect of requestAnimationFrame is defined by the HTML processing model, but we have not proposed any spec changes yet. Design doc.

The change your proposing does violate the spec, right?  In particular, I assume cross-origin iframes are always "associated with" the same event loop as their containing document.  It's not clear to me whether your design document defines the behavior change precisely enough for future interoperability.  Would it be reasonable to produce a pull request for the HTML5 spec with the exact changes you'd want, and then ask for feedback (eg. maybe via the new WICG) from other experts on the HTML processing model?

Summary

We want to stop running requestAnimationFrame callbacks for frames which aren't visible in the viewport. This helps to avoid unnecessary work for animations which aren't going to be seen by the user.

Motivation

The requestAnimation mechanism is a great way for pages to synchronize their animations with the display and the browser's own rendering. However, because there isn't an easy way to find out which parts of a page are visible, most pages end up perpetually subscribing to animation frame updates, causing unnecessary processing for animations which aren't even on the screen. A typical example is a long page with several ads (e.g., 500962, 447731, 395245, 515517, case study -- sorry, internal only, I'll see if we can make this public).

We think the long term solution to this problem is to bring better visibility and viewability APIs to the web. Because that will take some time and require content to be updated, this Intent proposes an optimization for today's web: if the browser can determine that the document which is being animated is invisible (e.g., its frame is outside the viewport bounds), the animation callbacks for that document won't be executed until the document becomes visible again.

Compatibility Risk

To minimize the compatibility risk with existing content, we are only planning to throttle requestAnimationFrame callbacks for documents in cross 

origin frames. Because cross origin frames can't synchronously interact with the outside world, there isn't a direct way to observe the exact timing of animation updates in the embedded document.

But that doesn't mean it's not observable.  Eg. a site could rely on communicating with a cross-origin iframe (eg. via postMessage) which happens to depend on raf to do it's work.  So there's at least some risk of breakage here, right?  Do you have any compat data?

I can't think of an easy automated way to measure this.  But perhaps we should at least implement behind a flag and do a bit of testing before deciding if this is something we should try shipping?

Note that pages already have to deal with requestAnimationFrame updates stopping completely when the tab is in the background.

Firefox: Shipped in Firefox 40 (however they throttle to 1 Hz instead of stopping completely and don't have the cross origin restriction.)

Do you know why they chose 1 Hz?  Perhaps they have examples of sites that break that would be useful to us?  Have there been any discussions about the need (or not) to update the spec to permit this change?

Internet Explorer: No public signals

Safari: No public signals

Have you solicited feedback from any of the other vendors on this?  This seems like the sort of change that both Safari and IE performance teams would like, and may have even investigated already.  Personally I don't think we need to get consensus before we ship a change like this (like you say, it's mostly a hard-to-observe implementation detail).  But it may be worth at least having some discussion about it.  Eg. if anyone has a reason why this might be bad for the web (known site compat problems) then it would be nice to know in advance :-). 

 

Web developers: No signals

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

None. (Implementation tracking bug: crbug.com/487937)

As per Jochen's request, please create one (we'll probably want to blog about it, etc.).  In this case it may be fine to just add the missing labels to your implementation bug, and add a link to the chromestatus entry as a comment.

[Anne van Kesteren]

On Tue, Aug 4, 2015 at 4:52 AM, Rick Byers <rby...@chromium.org> wrote:
> The change your proposing does violate the spec, right? In particular, I
> assume cross-origin iframes are always "associated with" the same event loop
> as their containing document.

Why would you assume that? That is only true if they can reach each
other through document.domain:
https://html.spec.whatwg.org/#unit-of-related-similar-origin-browsing-contexts


--
https://annevankesteren.nl/

[Sami Kyostila]

Thanks for the comments Rick!

2015-08-04 3:52 GMT+01:00 Rick Byers <rby...@chromium.org>:

I'm excited to see this work going forward!  Reducing the performance impact of iframes is essential to Blink's top goals, so this is urgent.  However, it's not clear to me that this is ready to ship yet.  A few questions inline.

On Mon, Aug 3, 2015 at 1:32 PM, Sami Kyostila <skyo...@chromium.org> wrote:

Contact emails

skyo...@chromium.org

Spec

This aspect of requestAnimationFrame is defined by the HTML processing model, but we have not proposed any spec changes yet. Design doc.

The change your proposing does violate the spec, right?  In particular, I assume cross-origin iframes are always "associated with" the same event loop as their containing document.  It's not clear to me whether your design document defines the behavior change precisely enough for future interoperability.  Would it be reasonable to produce a pull request for the HTML5 spec with the exact changes you'd want, and then ask for feedback (eg. maybe via the new WICG) from other experts on the HTML processing model?

Sure, that sounds like a useful exercise to go through. Based on my reading (I'm not a spec language lawyer), the browser is only allowed to limit rendering updates based on the top-level browsing context's state, whereas we're proposing to use what I think amounts to the state of the related similar-origin browsing contexts (which Anne linked to).

 

Summary

We want to stop running requestAnimationFrame callbacks for frames which aren't visible in the viewport. This helps to avoid unnecessary work for animations which aren't going to be seen by the user.

Motivation

The requestAnimation mechanism is a great way for pages to synchronize their animations with the display and the browser's own rendering. However, because there isn't an easy way to find out which parts of a page are visible, most pages end up perpetually subscribing to animation frame updates, causing unnecessary processing for animations which aren't even on the screen. A typical example is a long page with several ads (e.g., 500962, 447731, 395245, 515517, case study -- sorry, internal only, I'll see if we can make this public).

We think the long term solution to this problem is to bring better visibility and viewability APIs to the web. Because that will take some time and require content to be updated, this Intent proposes an optimization for today's web: if the browser can determine that the document which is being animated is invisible (e.g., its frame is outside the viewport bounds), the animation callbacks for that document won't be executed until the document becomes visible again.

Compatibility Risk

To minimize the compatibility risk with existing content, we are only planning to throttle requestAnimationFrame callbacks for documents in cross 

origin frames. Because cross origin frames can't synchronously interact with the outside world, there isn't a direct way to observe the exact timing of animation updates in the embedded document.

But that doesn't mean it's not observable.  Eg. a site could rely on communicating with a cross-origin iframe (eg. via postMessage) which happens to depend on raf to do it's work.  So there's at least some risk of breakage here, right?  Do you have any compat data? 

 

I can't think of an easy automated way to measure this.  But perhaps we should at least implement behind a flag and do a bit of testing before deciding if this is something we should try shipping?

 

Right, I didn't meant to imply that the cross origin restriction was a bulletproof way to avoid issues -- it's just a way to reduce risk. You could still have a round trip setup like you described where the cross origin rAF is part of the loop.

I suppose we could try having a use counter for cross origin postMessages in a rAF context, but even that won't be foolproof. I'm not sure if that's more trouble than it's worth or whether we should just do more testing on the dev channel.

In any case, I'd be happy to land this behind a flag first. (Aside: is there a way to have a feature flag that's automatically on for dev or beta builds? Without that I don't think we'll have enough coverage.)

Note that pages already have to deal with requestAnimationFrame updates stopping completely when the tab is in the background.

Firefox: Shipped in Firefox 40 (however they throttle to 1 Hz instead of stopping completely and don't have the cross origin restriction.)

Do you know why they chose 1 Hz?  Perhaps they have examples of sites that break that would be useful to us?  Have there been any discussions about the need (or not) to update the spec to permit this change?

I didn't see any discussion of the throttling rate, but from the patch it looks like they reused the mechanism to throttle background tabs which defaults to 1 Hz. As for spec changes, Seth Fowler (who implemented this for Firefox) started a thread on whatwg proposing that Page Visibility could take viewport visibility into account too. However it turned out that would have more far reaching consequences than anticipated (earlier thread), so discussion died down.

FWIW why we chose to stop the callbacks completely instead of 1 Hz was that intuitively it didn't seem sensible to keep updating hidden animations. We don't do that for background tabs either.

Internet Explorer: No public signals

Safari: No public signals

Have you solicited feedback from any of the other vendors on this?  This seems like the sort of change that both Safari and IE performance teams would like, and may have even investigated already.  Personally I don't think we need to get consensus before we ship a change like this (like you say, it's mostly a hard-to-observe implementation detail).  But it may be worth at least having some discussion about it.  Eg. if anyone has a reason why this might be bad for the web (known site compat problems) then it would be nice to know in advance :-). 

I haven't asked for specific feedback yet, but lemme kick off a thread on public-web-perf and report back.

 

Web developers: No signals

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

None. (Implementation tracking bug: crbug.com/487937)

As per Jochen's request, please create one (we'll probably want to blog about it, etc.).  In this case it may be fine to just add the missing labels to your implementation bug, and add a link to the chromestatus entry as a comment.

Ah, I missed that. I made a new one to keep things clear: https://code.google.com/p/chromium/issues/detail?id=516640

[Chris Harrelson]

On Tue, Aug 4, 2015 at 4:43 AM, Sami Kyostila <skyo...@chromium.org> wrote:

Thanks for the comments Rick!

2015-08-04 3:52 GMT+01:00 Rick Byers <rby...@chromium.org>:

I'm excited to see this work going forward!  Reducing the performance impact of iframes is essential to Blink's top goals, so this is urgent.  However, it's not clear to me that this is ready to ship yet.  A few questions inline.

On Mon, Aug 3, 2015 at 1:32 PM, Sami Kyostila <skyo...@chromium.org> wrote:

Contact emails

skyo...@chromium.org

Spec

This aspect of requestAnimationFrame is defined by the HTML processing model, but we have not proposed any spec changes yet. Design doc.

The change your proposing does violate the spec, right?  In particular, I assume cross-origin iframes are always "associated with" the same event loop as their containing document.  It's not clear to me whether your design document defines the behavior change precisely enough for future interoperability.  Would it be reasonable to produce a pull request for the HTML5 spec with the exact changes you'd want, and then ask for feedback (eg. maybe via the new WICG) from other experts on the HTML processing model?

Sure, that sounds like a useful exercise to go through. Based on my reading (I'm not a spec language lawyer), the browser is only allowed to limit rendering updates based on the top-level browsing context's state, whereas we're proposing to use what I think amounts to the state of the related similar-origin browsing contexts (which Anne linked to).

 

Summary

We want to stop running requestAnimationFrame callbacks for frames which aren't visible in the viewport. This helps to avoid unnecessary work for animations which aren't going to be seen by the user.

Motivation

The requestAnimation mechanism is a great way for pages to synchronize their animations with the display and the browser's own rendering. However, because there isn't an easy way to find out which parts of a page are visible, most pages end up perpetually subscribing to animation frame updates, causing unnecessary processing for animations which aren't even on the screen. A typical example is a long page with several ads (e.g., 500962, 447731, 395245, 515517, case study -- sorry, internal only, I'll see if we can make this public).

We think the long term solution to this problem is to bring better visibility and viewability APIs to the web. Because that will take some time and require content to be updated, this Intent proposes an optimization for today's web: if the browser can determine that the document which is being animated is invisible (e.g., its frame is outside the viewport bounds), the animation callbacks for that document won't be executed until the document becomes visible again.

Compatibility Risk

To minimize the compatibility risk with existing content, we are only planning to throttle requestAnimationFrame callbacks for documents in cross 

origin frames. Because cross origin frames can't synchronously interact with the outside world, there isn't a direct way to observe the exact timing of animation updates in the embedded document.

But that doesn't mean it's not observable.  Eg. a site could rely on communicating with a cross-origin iframe (eg. via postMessage) which happens to depend on raf to do it's work.  So there's at least some risk of breakage here, right?  Do you have any compat data? 

 

I can't think of an easy automated way to measure this.  But perhaps we should at least implement behind a flag and do a bit of testing before deciding if this is something we should try shipping?

 

Right, I didn't meant to imply that the cross origin restriction was a bulletproof way to avoid issues -- it's just a way to reduce risk. You could still have a round trip setup like you described where the cross origin rAF is part of the loop.

I suppose we could try having a use counter for cross origin postMessages in a rAF context, but even that won't be foolproof. I'm not sure if that's more trouble than it's worth or whether we should just do more testing on the dev channel.

In any case, I'd be happy to land this behind a flag first. (Aside: is there a way to have a feature flag that's automatically on for dev or beta builds? Without that I don't think we'll have enough coverage.)

Do you mean dev and beta but not stable? There is no way to do that.

 

Note that pages already have to deal with requestAnimationFrame updates stopping completely when the tab is in the background.

Firefox: Shipped in Firefox 40 (however they throttle to 1 Hz instead of stopping completely and don't have the cross origin restriction.)

Do you know why they chose 1 Hz?  Perhaps they have examples of sites that break that would be useful to us?  Have there been any discussions about the need (or not) to update the spec to permit this change?

I didn't see any discussion of the throttling rate, but from the patch it looks like they reused the mechanism to throttle background tabs which defaults to 1 Hz. As for spec changes, Seth Fowler (who implemented this for Firefox) started a thread on whatwg proposing that Page Visibility could take viewport visibility into account too. However it turned out that would have more far reaching consequences than anticipated (earlier thread), so discussion died down.

FWIW why we chose to stop the callbacks completely instead of 1 Hz was that intuitively it didn't seem sensible to keep updating hidden animations. We don't do that for background tabs either.

Internet Explorer: No public signals

Safari: No public signals

Have you solicited feedback from any of the other vendors on this?  This seems like the sort of change that both Safari and IE performance teams would like, and may have even investigated already.  Personally I don't think we need to get consensus before we ship a change like this (like you say, it's mostly a hard-to-observe implementation detail).  But it may be worth at least having some discussion about it.  Eg. if anyone has a reason why this might be bad for the web (known site compat problems) then it would be nice to know in advance :-). 

I haven't asked for specific feedback yet, but lemme kick off a thread on public-web-perf and report back.

 

Web developers: No signals

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

None. (Implementation tracking bug: crbug.com/487937)

As per Jochen's request, please create one (we'll probably want to blog about it, etc.).  In this case it may be fine to just add the missing labels to your implementation bug, and add a link to the chromestatus entry as a comment.

Ah, I missed that. I made a new one to keep things clear: https://code.google.com/p/chromium/issues/detail?id=516640

Link to entry on the feature dashboard

https://www.chromestatus.com/features/4514713492783104

Requesting approval to ship?

Yes.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

Sorry, I meant in the blink implementation specifically.  Today in blink cross-origin iframes run on the same thread and so I assume share the same event loop according to the definition in the spec - right?  In what ways is this visible to the application?

More generally, I'd love to hear to what extent you feel Firefox's new behavior and our proposed behavior conform to the spec.  I'm just trying to better evaluate the compat / interop risks here.

--
https://annevankesteren.nl/

[Rick Byers]

On Tue, Aug 4, 2015 at 11:18 AM, Chris Harrelson <chri...@chromium.org> wrote:

On Tue, Aug 4, 2015 at 4:43 AM, Sami Kyostila <skyo...@chromium.org> wrote:

Thanks for the comments Rick!

2015-08-04 3:52 GMT+01:00 Rick Byers <rby...@chromium.org>:

I'm excited to see this work going forward!  Reducing the performance impact of iframes is essential to Blink's top goals, so this is urgent.  However, it's not clear to me that this is ready to ship yet.  A few questions inline.

On Mon, Aug 3, 2015 at 1:32 PM, Sami Kyostila <skyo...@chromium.org> wrote:

Contact emails

skyo...@chromium.org

Spec

This aspect of requestAnimationFrame is defined by the HTML processing model, but we have not proposed any spec changes yet. Design doc.

The change your proposing does violate the spec, right?  In particular, I assume cross-origin iframes are always "associated with" the same event loop as their containing document.  It's not clear to me whether your design document defines the behavior change precisely enough for future interoperability.  Would it be reasonable to produce a pull request for the HTML5 spec with the exact changes you'd want, and then ask for feedback (eg. maybe via the new WICG) from other experts on the HTML processing model?

Sure, that sounds like a useful exercise to go through. Based on my reading (I'm not a spec language lawyer), the browser is only allowed to limit rendering updates based on the top-level browsing context's state, whereas we're proposing to use what I think amounts to the state of the related similar-origin browsing contexts (which Anne linked to).

Thanks, makes sense.  I personally wouldn't block shipping this change on having the language perfect, but it certainly seems worth a discussion with the spec experts (maybe on the WhatWG list).  Especially since Firefox behavior is changing too. 

Summary

We want to stop running requestAnimationFrame callbacks for frames which aren't visible in the viewport. This helps to avoid unnecessary work for animations which aren't going to be seen by the user.

Motivation

The requestAnimation mechanism is a great way for pages to synchronize their animations with the display and the browser's own rendering. However, because there isn't an easy way to find out which parts of a page are visible, most pages end up perpetually subscribing to animation frame updates, causing unnecessary processing for animations which aren't even on the screen. A typical example is a long page with several ads (e.g., 500962, 447731, 395245, 515517, case study -- sorry, internal only, I'll see if we can make this public).

We think the long term solution to this problem is to bring better visibility and viewability APIs to the web. Because that will take some time and require content to be updated, this Intent proposes an optimization for today's web: if the browser can determine that the document which is being animated is invisible (e.g., its frame is outside the viewport bounds), the animation callbacks for that document won't be executed until the document becomes visible again.

Compatibility Risk

To minimize the compatibility risk with existing content, we are only planning to throttle requestAnimationFrame callbacks for documents in cross 

origin frames. Because cross origin frames can't synchronously interact with the outside world, there isn't a direct way to observe the exact timing of animation updates in the embedded document.

But that doesn't mean it's not observable.  Eg. a site could rely on communicating with a cross-origin iframe (eg. via postMessage) which happens to depend on raf to do it's work.  So there's at least some risk of breakage here, right?  Do you have any compat data? 

 

I can't think of an easy automated way to measure this.  But perhaps we should at least implement behind a flag and do a bit of testing before deciding if this is something we should try shipping?

 

Right, I didn't meant to imply that the cross origin restriction was a bulletproof way to avoid issues -- it's just a way to reduce risk. You could still have a round trip setup like you described where the cross origin rAF is part of the loop.

I suppose we could try having a use counter for cross origin postMessages in a rAF context, but even that won't be foolproof. I'm not sure if that's more trouble than it's worth or whether we should just do more testing on the dev channel.

In any case, I'd be happy to land this behind a flag first. (Aside: is there a way to have a feature flag that's automatically on for dev or beta builds? Without that I don't think we'll have enough coverage.)

Do you mean dev and beta but not stable? There is no way to do that.

Step 1 I think is to land this behind a flag and do some ad-hoc testing (i.e. have a handful of folks run with it enabled).  If that goes well and we don't hear concrete concerns from the discussion elsewhere (eg. other vendors / web developers) then maybe trying to ship is the right next step.  Or if we have increasing cause for concern, we could try to collect some measurements like you suggest or even do a field trial.  We don't want feature differences between beta and stable, but we are willing to use Finch to enable features for a small percentage of users.  That might be overkill here though, let's see what others think. 

Note that pages already have to deal with requestAnimationFrame updates stopping completely when the tab is in the background.

Firefox: Shipped in Firefox 40 (however they throttle to 1 Hz instead of stopping completely and don't have the cross origin restriction.)

Do you know why they chose 1 Hz?  Perhaps they have examples of sites that break that would be useful to us?  Have there been any discussions about the need (or not) to update the spec to permit this change?

I didn't see any discussion of the throttling rate, but from the patch it looks like they reused the mechanism to throttle background tabs which defaults to 1 Hz. As for spec changes, Seth Fowler (who implemented this for Firefox) started a thread on whatwg proposing that Page Visibility could take viewport visibility into account too. However it turned out that would have more far reaching consequences than anticipated (earlier thread), so discussion died down.

FWIW why we chose to stop the callbacks completely instead of 1 Hz was that intuitively it didn't seem sensible to keep updating hidden animations. We don't do that for background tabs either.

Agreed, I prefer stopping completely if we can pull it off.  Can you just reach out to the FF dev and ask if they're aware of any sites that would break?

Internet Explorer: No public signals

Safari: No public signals

Have you solicited feedback from any of the other vendors on this?  This seems like the sort of change that both Safari and IE performance teams would like, and may have even investigated already.  Personally I don't think we need to get consensus before we ship a change like this (like you say, it's mostly a hard-to-observe implementation detail).  But it may be worth at least having some discussion about it.  Eg. if anyone has a reason why this might be bad for the web (known site compat problems) then it would be nice to know in advance :-). 

I haven't asked for specific feedback yet, but lemme kick off a thread on public-web-perf and report back.

Perfect, thank you! 

[Kenji Baheux]

Here is a publicly shared version of the case study mentioned by Sami in his first email.

Re: feedback from other vendors 

I haven't check the thread on public-web-perf but based on the following tweet, Simon Fraser might be the right person to engage with for Safari.

"Please don't use requestAnimationFrame to do work in offscreen scenarios (e.g. display:none iframes). Use only for visible animation."

 https://twitter.com/smfr/status/616325089944932352 

Best,

[Sami Kyostila]

Thanks Kenji.

I've been talking to some folks about the implementation details here, and we've come to the conclusion that singling out requestAnimationFrame as the thing to throttle seems a little arbitrary. Instead, it would be better to suppress the entire animate/layout/paint pipeline for the affected frames. This avoids doing any rendering work for hidden frames regardless of whether it was caused by rAF or something else. Backgrounded tabs also work the same way.

The downside is that the implementation will be slightly more complex and the potential for breakage higher since more things will be affected. I think this (plus all the things that Rick mentioned) is reason enough for me to downgrade this Intent just for the implementation part and do everything behind a flag.

- Sami

[Rick Byers]

Thanks Sami, that sounds like a great plan.  Once you've got an implementation and some experience using it, I'm sure the path to shipping will be much more straight forward.