LGTM2 under the same conditions, for one last extension here.
On Fri, Feb 11, 2022 at 11:14 AM Mike West <mk...@chromium.org> wrote:
Hey Emanuel,
API owners discussed this intent this week and the week before,
with a fair amount of skepticism around the length of the
experimentation (April 2021 (90) - May 2022 (101)), and the value
of continuing this experiment in light of what looks like
reasonable alignment from our colleagues in WebKit and Gecko on
the Access Handles proposal which y'all are working through in
parallel. With that in mind, the best path forward would be to let
this experiment expire rather than extending it. Unfortunately, it
appears that some miscommunication led a partner to begin relying
on this API in ways that make it difficult for us to simply remove
support. This puts us in a bit of a pickle.
I'd like to ensure that we don't end up in this situation again in
3 months if we extend this OT to give the partner time to migrate
off of Storage Foundation. I think we have solid commitments from
them that they'll be able to shift onto Access Handles in the
timeframe we're discussing, and I think we can strengthen that
encouragement by allowing them to extend their OT tokens once, and
then disabling new signups for the OT to ensure that new partners
don't accidentally land on this instead of Access Handles. That's
a compromise that seems to me to minimize the incremental risk of
burn-in, while allowing us to remove this API from the platform
without user-visible breakage. But it's an unusual extension, so I
don't think a single LGTM is sufficient to approve it.
LGTM1 to extend the trial to 101 _and_ disable new signups or
renewals. Ideally, the partner can complete their migration before
101, in which case we can end the trial earlier. I'd appreciate
other API owners weighing in.
-mike
On Tue, Feb 1, 2022 at 4:55 PM Emanuel Krivoy
<fived...@chromium.org> wrote:
Hi Chris,
Replies inline as well:
Is it accurate to say then that there hasn't been
substantial use on sites recently? Or are they using it
generally but just haven't run the set of tests yet?
The latter, Photoshop Web used Storage Foundation generally,
and is now using Access Handles. Another partner has started a
set test on their project, which would include feedback on the
difference between the APIs from the perspective of new use
cases.
Also, could you summarize the feedback from partners so
far on this origin trial?
Feedback from partners has been very positive: Photoshop Web
reported that both APIs critically unblocked their site, and
did not see significant impact after transitioning to Access
Handles. They use the API as a general purpose storage backend
that can be performantily/easily accessed from Wasm, as well
as a way to manage memory consumption during image editing.
The other partner is also relying on Storage Foundation for
critical bits of their project, although we've gotten less
detailed feedback so far.
On Thu, Jan 20, 2022 at 6:44 PM Chris Harrelson
<chris...@chromium.org> wrote:
Hi Emanuel,
A question inline below.
On Thu, Jan 20, 2022 at 7:02 AM Emanuel Krivoy
<fived...@chromium.org> wrote:
Hello blink-dev,
We’d like to ask for an extension to our Origin Trial,
from M99 to M101. As mentioned in our previous I2E
<https://groups.google.com/a/chromium.org/g/blink-dev/c/enA3o1UvzcE/m/qsaC_2whAQAJ>,
our partner intended to run a final series of tests
that would allow us to measure the impact of the
changes between Storage Foundation and its successor
Access Handles. The tests were postponed but should
happen in the near future, therefore we’d like to
continue having concurrent Access Handle/Storage
Foundation trials.
Is it accurate to say then that there hasn't been
substantial use on sites recently? Or are they using it
generally but just haven't run the set of tests yet?
Also, could you summarize the feedback from partners so
far on this origin trial?
Please find the Chrome Status template below:
Contact emails
fived...@chromium.org, r...@chromium.org
Explainer
https://github.com/WICG/storage-foundation-api-explainer
<https://github.com/WICG/storage-foundation-api-explainer>
Specification
N/A
Summary
Storage Foundation API is a storage API that resembles
a very basic filesystem, with direct access to stored
data through buffers and offsets. Our goal is to give
developers flexibility by providing generic, simple,
and performant primitives upon which they can build
higher-level components. It's particularly well suited
for Wasm-based libraries and applications that want to
use custom storage algorithms to fine-tune execution
speed and memory usage.
Blink component
Blink>Storage
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage>
Search tags
storage
<https://chromestatus.com/features#tags:storage>,nativeio
<https://chromestatus.com/features#tags:nativeio>,performance
<https://chromestatus.com/features#tags:performance>,low-level
<https://chromestatus.com/features#tags:low-level>,generic
<https://chromestatus.com/features#tags:generic>,foundation
<https://chromestatus.com/features#tags:foundation>
TAG review
https://github.com/w3ctag/design-reviews/issues/566
<https://github.com/w3ctag/design-reviews/issues/566>
TAG review status
Closed
Risks
Interoperability and Compatibility
This new feature has some potential interoperability
risks due to its nature as a novel and low-level API.
Currently, there are no web features that expose such
a generic interface and that focus on WebAssembly
ports as one of it's main consumers.
We've also received feedback from other vendors that
the functionality added in Storage Foundation API
seems duplicative of File System Access API. We are
exploring a merged design (details
here:https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec
<https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec>)
while collecting feedback and validating design
choices with this independent API.
Gecko: Negative
(https://github.com/mozilla/standards-positions/issues/481
<https://github.com/mozilla/standards-positions/issues/481>)
Supportive of a low-level storage API, opposed to
minting a new API instead of taking a holistic
approach to file access
WebKit: Negative
(https://lists.webkit.org/pipermail/webkit-dev/2021-February/031687.html
<https://lists.webkit.org/pipermail/webkit-dev/2021-February/031687.html>)
No opposition to offering efficient access to files,
strongly opposed to minting a new API instead of
augmenting an existing one.
Web developers: No signals
Goals for experimentation
In general, we would like to validate the whole
surface of our API against developer expectations and
more diverse use cases. In particular, we are
interested in confirming that we provide the required
performance to allow new uses, and to shed light on
developer preference between a synchronous and
asynchronous surface.
Reason this experiment is being extended
We added a new surface on OPFS (Access
Handles:https://github.com/WICG/file-system-access/blob/main/AccessHandle.md
<https://github.com/WICG/file-system-access/blob/main/AccessHandle.md>)
that replaces Storage Foundation. Having concurrent
trials would help us validate the surface by comparing
and contrasting it with the previous one. Our partner
will run a final series of tests with beta users, and
this provides a chance for us to measure the impact of
some of the design decisions we’ve made. In particular
we’d like to see the effect of providing a mixed
sync/async surface on SyncAccessHandles and of all
filesystem operations being async. Concurrent trials
would also make it easier to measure any unexpected
performance differences.
Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux, Chrome
OS, Android, and Android WebView)?
Yes
Is this feature fully tested
byweb-platform-tests
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
Yes
Flag name
NativeIO
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=914488
<https://bugs.chromium.org/p/chromium/issues/detail?id=914488>
Launch bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1143306
<https://bugs.chromium.org/p/chromium/issues/detail?id=1143306>
Estimated milestones
OriginTrial desktop last
98
OriginTrial desktop first
90
OriginTrial android last
98
OriginTrial android first
90
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5670244905385984
<https://chromestatus.com/feature/5670244905385984>
Links to previous Intent discussions
Intent to
prototype:https://groups.google.com/a/chromium.org/g/blink-dev/c/gh0gTHO18YQ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/gh0gTHO18YQ>
Intent to
Experiment:https://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY
<https://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY>
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHExSGLmxBWbT2vuLX_cVWn8wrzqSF0w0bvN5dTkdYc0T63%3Dig%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHExSGLmxBWbT2vuLX_cVWn8wrzqSF0w0bvN5dTkdYc0T63%3Dig%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHExSGJ_Eeu_iONJ9ajZ3%2BQj-_RZ%2BDC7r_Ng_6etEQY479Ak2A%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHExSGJ_Eeu_iONJ9ajZ3%2BQj-_RZ%2BDC7r_Ng_6etEQY479Ak2A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdtZgi5oaBbhfVhVTt5%2Be2UnW1E1d%3DPaA2iXu8ubkh_1g%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdtZgi5oaBbhfVhVTt5%2Be2UnW1E1d%3DPaA2iXu8ubkh_1g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVKJKfWw-b3PWJLJiSBYHEcXOEFRHXbJQAe0JZSeogN6w%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVKJKfWw-b3PWJLJiSBYHEcXOEFRHXbJQAe0JZSeogN6w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
