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

I've filed bugs for the issues raised in this thread. We'll now work on updating the explainer to reflect those.

@kenchris :
> The launch event seems to happen in the service worker and be called "launch", but in the explainer you are handling this from the main document with the "load" event. So would both options be supported? and how would that work? Maybe worth adding to the explainer

Captured in WICG/file-handling#34.

@dbaron :
> One thought is that there seem to be a bunch of similarities between handling a file with a given MIME Type (or extension) that's already stored locally, and handling such a file that the user has downloaded from the web. That is, if your app can handle `application/atom+xml` off the local filesystem, it can probably handle that off of the Web too -- and maybe that should just work automatically without anything substantial needing to be done, if at that point it's the local applictaion handling `application/atom+xml`. On the other hand, one thing in the past that's led to overuse of `registerProtocolHandler` is that there are cases where file type handlers want the URL of the resource rather than the current representation of it. In other words, many handlers for `application/atom+xml` probably want to be able to re-fetch the feed at arbitrary later times rather than being concerned with just the current contents of the feed. Maybe we've already settled on using the hack of `registerProtocolHandler` with a fake protocol for that -- but it's a pretty unpleasant hack. (That is, `webcal` is really just `http`, but the fake protocol was invented to allow certain HTTP resources to be dispatched by-URL (rather than by-representation) to an app that handled calendars.)

So, I think this is out of scope of file handlers. What we're trying to build is specifically a way for websites to get the functionality of native apps opening real local files on disk: that is, being able to:

- Random-access read them (being able to seek around through the file without loading the whole thing), and
- Write back to them.

That's not to say an implementation _can't_ expose virtual file-like objects, or read-only files, to this API. But they need to have the same interface as a real file.

The use case you're discussing here, specifically, exposing the URL of a web resource as a read-only "file handle" that can be stored in a database and refetched by the server on on ongoing basis, is quite a different interface to that of a local file.

I think what you're proposing is a legitimate use case, but it's best addressed with `registerContentHandler`. The fact that that API never took off might suggest that it isn't an important enough use case to try and capture. Either way, I think it's different enough to what we're trying to do with file handling that I don't want to capture it within our scope.

> Another question is that of permissions. It seems like at some point the browser probably wants to ask the user for permission as to whether they want this particular installed web application to be able to access a particular file on the native file system. At the very least, it seems like a risk if there's no permission prompt anywhere in the system -- and it it at least seems like it might be easier to explain that stuff to users at use time rather than at registration time (since it's not clear that it's easy to explain to a user what a `application/foo` file is).

Captured in WICG/file-handling#35.

> It seems like many OSes have some sort of chooser model for that (which often have features such as remembering the choice). Will this be able to integrate well with such OS choosers? Or would it be problematic for the browser to register multiple web apps with different names and icons into such a chooser?

Captured in WICG/file-handling#37.

> the dependency on the native file system API might be a barrier to adoption by other browsers -- it might be that other browsers might be interested in implementing something with this set of capabilities but nonetheless aren't willing to implement the native file system api.  (I'm not at all sure about this -- just speculating without having given it a lot of thought -- although I think there's a bunch of resistence to the native file system API.)

I hope this isn't a barrier to adoption, but if it is, I think it's too bad. The native file system API captures exactly the feature set we want here. (In fact, the two APIs were co-designed, initially part of the same proposal but split up because we saw an opportunity to do so and work on them in parallel; I recall those discussions started at TPAC 2018.) If folks are opposed to native file system API then I would rather try and convince them to adopt both of these proposals than water down file-handling (e.g., making it read-only).

-- 
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-561972997