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

I'm looking at this with @kenchris in a breakout at the TAG meeting right now.

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.

At the very least, it seems like perhaps the explainer should talk a little bit more about how this gets used both for already-local files and files coming from the web -- but it would also be interesting if there were a better solution for the "want the URL rather than the representation" problem.

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