Re: [w3ctag/design-reviews] File Handling (#371)

> At the same time, I think this might provide the functionality I was talking about [websites able to open files from URLs rather than on disk] for free.
> 
> Say, for example, https://calendar.google.com/ uses the File Handling API to say that it supports handing `.ics` files (`text/calendar`) so that a user choosing an ICS file in the OS's file browser will load Google Calendar's ICS importer. However, then, if a user browsing the web clicks on an ICS file... typically what the browser does in that case is show a dialog that offers to use whatever the OS handler for ICS files is... which in this case is the browser running Google Calendar mediated by this File Handling API. So maybe it just works. (Or if it doesn't work, maybe Firefox will load Google Calendar in Chrome, and Chrome will load Google Calendar in Firefox, providing both browsers an incentive to do it right!)

Yes. This is the intention, and should come for free, as you said. Browsers could implement special handling for their download mechanism that automatically allows downloaded files to be opened in a registered file handler, rather than passing it to the OS (similar to how Chrome opens PDF files inside itself, or for that matter how any browser handles HTML files). Or, they could just pass it to the OS which may end up passing it right back to the browser again. Either way, that's fine and doesn't really require spec support.

However, what you were talking about earlier in the thread was the specific example of an RSS reader registering as a handler for `application/atom+xml`, and instead of being given the contents of the file, being given the URL to the RSS feed resource. The critical difference with being given the URL is that the site is able to fetch the contents of the document on the server backend, rather than it being done by the browser, and is able to re-fetch the contents at any time in the future. I said that was out of scope because it's a totally different design to what we have now, for a totally different use case. If the interface was "you get a URL", then we would have to create virtual URLs to represent local files on the user's disk, but then those virtual URLs would not be fetchable by the server. There are also auth, intranet and same-origin policy problems with this: (auth and intranet are problems for server-side fetching, while same-origin policy affects client-side fetching). It's a reasonable feature to want, but it provides a rather orthogonal set of use cases than the API we have designed.

I'll look at your other comments later.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/371#issuecomment-594320872