That sounds generally reasonable to me, with the main caveat being that deprecations require a clear timeline, and having one requires understanding of usage and having a plan for driving it down. It might be worthwhile to dig into usage and see who the main culprits are, and then try some targeted outreach to get them to move off of filesystem://
On Wed, Feb 9, 2022 at 2:44 AM Brianna Goldstein <brgoldst...@chromium.org> wrote: > Hey all, following up with a proposed plan for moving forward here - > > > The Chrome Storage team considers the old Filesystem API to be an undesirable > API > <https://docs.google.com/document/d/124tXWslkhRH992-SNfaJriHk7go8o6Hg9IH_FPG96n8/edit#heading=h.4hewn7h3cigt>, > one that should eventually be deprecated and removed. Our short-term goal > is to partition storage APIs > <https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md>, > but Android media playback from filesystem:// URLs is the one codepath > where this is not easily done. Given it’s near-zero usage, we’d like to > remove it instead. However, it is a bit awkward to only remove this one use > case on this one platform, especially since we want to eventually remove it > everywhere. So, in order to meet both our short-term needs and the Storage > team’s long-term goals we propose the following: > > > 1. > > Remove support for media playback from filesystem:// URLs on Chrome on > Android (the original proposal in this thread). > 2. > > Remove support for media playback from filesystem:// across all > platforms. > 3. > > Eventually, remove support for filesystem://. > > > In order to get to steps 2 and 3 we need to: > > 1. > > Formally deprecate filesystem://, sending devtools Issues and > deprecation reports. We’ll work on I2Ds for both 2 and 3 with detailed > timelines (as they emerge). > 2. > > Add an Enterprise policy to allow more time for migration, and > possibly a deprecation trial as well > 3. > > Work with DevRel to write an article recommending workarounds and a > migration path > 4. > > Work with internal and external partners to ensure we can drive down > usage to a level where we’re comfortable removing filesystem://. We’ll > focus efforts on ChromeOS media playback first. > 5. > > Investigate adding capabilities to the platform that addresses the use > cases of media playback from Cache storage without requiring a > ServiceWorker > > > > Brianna > > On Fri, Feb 4, 2022 at 3:26 AM PhistucK <phist...@gmail.com> wrote: > >> > I'm not sure if that's a legit URL if it doesn't have a double-slash >> after the first colon. >> Double-slash is not a requirement for all URL/URIs, for example, >> data:text/html,bla. file: uses triple-slash and so on... >> (Not entirely sure regarding URL versus URI, if you meant specifically >> the former and not the latter) >> The scheme/protocol specifies the format after the colon, but the general >> "how to write a URL/URI" does not mandate anything in this regard, I think. >> >> ☆*PhistucK* >> >> >> On Fri, Feb 4, 2022 at 1:37 AM Nigel Tao <nigel...@chromium.org> wrote: >> >>> On Thu, Jan 27, 2022 at 3:23 AM Brianna Goldstein >>> <brgoldst...@chromium.org> wrote: >>> >On Thu, Jan 27, 2022 at 2:49 AM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >> At the risk of piling on with another question: are these URLs >>> different from `file://` scheme URLs? >>> > >>> > @Yoav Weiss yes these are from the `filesystem://` scheme which is >>> different from `file://`. Here's some information about where this scheme >>> comes from. >>> >>> I'll ask another naive question... >>> >>> I understand "file://" URLs. "file:///home/user/bar.txt" is an example. >>> >>> Can you give some examples of "filesystem://" URLs? Do they look like >>> "filesystem:///home/user/bar.txt" or >>> "filesystem://example.domain/foo/bar.txt" or something else? Do these >>> URLs look different for Android versus Desktop? Do they look different >>> for Browser App versus Web View? >>> >>> Your "Here's" link points to >>> https://www.iana.org/assignments/uri-schemes/historic/filesystem which >>> doesn't give an example, nor does the >>> https://www.w3.org/TR/file-system-api/ or >>> http://www.html5rocks.com/en/tutorials/file/filesystem/ (which >>> redirects to https://web.dev/read-files/) links from its references. >>> >>> pwnall@ later linked to >>> https://dev.w3.org/2009/dap/file-system/file-dir-sys.html and >>> https://wicg.github.io/file-system-access/ and the only example URL is >>> "Proposal currently under discussion: Use a format such as >>> filesystem: >>> http://example.domain/persistent-or-temporary/path/to/file.html"; >>> but even if it's more than a proposal, I'm not sure if that's a legit >>> URL if it doesn't have a double-slash after the first colon. >>> >>> -- >>> 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/CAEdON6acwSf5c2uJ7ZWgJa32q7tnj%2B%2Bcobqc5Mw3ksu2pFUHXg%40mail.gmail.com >>> . >>> >> -- 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/CAL5BFfUKxOO1TNu5HhVathRa%2BpKK7v%2BrK_un4cOjVsVq2wH6Qw%40mail.gmail.com.
