Determining LaunchURL for a list of files.

[fallaciousreasoning]

Most operating systems append files as command line arguments to an executable. This presents a problem when determining which url to open to handle the files.

For example, if there are two file handlers one which opens /open-csv and the other which opens /open-svg (as in the current explainer) it may be difficult for the user agent to determine which url to open.

In the file has an extension, the solution is easy: Use the handler that supports that file extension (or the first, if there's overlap). For example foo.csv should launch /open-csv while bar.svg should launch /open-svg. However, when the file only has a mimetype, it is much more difficult to determine the launch url. In order to decide which handler to use for the file foobar the user agent must talk to the operating system (custom mime types may be registered). This is not insurmountable, but it is inconvenient.

I was thinking about this today and was wondering if we can get away with a single action url, which would let us avoid this problem entirely (making the proposal much more similar to @ericwilligers' original explainer, and bringing it more in line with WebShareTarget).

With this change, a manifest might look like this (I've included a few extra fields, as I think it helps make what things are for clearer):

{
  "name": "Grafr",
  "file_handler": {
    // Where handled files should go.
    "action": "/open-graph",
    // All the types of file that can be handled by the app.
    "file_types": [
      {
       // A description of the file. Displayed in the OS when the app is the default handler for a file.
        "file_type_name": "Raw Graph",
        // A list of ImageResources to use as the thumbnail when the app is the default handler for a file.
        "file_thumbnails": [{ "src": "/csv-thumbnail.png"}],
        // The mimetypes and extensions that constitute this file type.
        "accept": {
          "text/csv": ".csv"
        }
      },
      {
        "file_type_name": "SVG Graph",
        "accept": {
          "image/svg+xml": ".svg"
        }
      },
      {
        "file_type_name": "Grafr File",
        "accept": {
          "application/vnd.grafr.graph": [ ".grafr", ".graf" ],
          "application/vnd.alternative-graph-app.graph": ".graph"
        }
      }
    ]
  }
}

The file_handler property specifies how files should be handled, while the file_types property inside it specifies which types of files it supports.

I suspect (but have no evidence) that apps will often have to check a file themselves before deciding how to handle a file (i.e do you parse an image/*?), so this might not even have much impact on ease of use.

@mgiuca do you have any thoughts on this?

[mgiuca]

Hmm. I think most apps will want to funnel all their handlers into a single URL which can then do work to figure out the file format.

But some will want us to split to separate URLs on their behalf. Consider an office app that wants to load documents, spreadsheets and presentations at a dedicated URL for each (which loads a completely different codebase). How would such an app work if we gave them only one endpoint?

Perhaps they could open files at "/open" which then redirects to the doc, sheet or slide URL, but is it going to be possible to pass a file handle through a redirect?

I think the easiest thing is to just keep things the way they were, but leave the question of multiple file types mapping onto different handlers unresolved, by saying if multiple handlers can handle a particular file, the user agent can choose one arbitrarily (i.e., don't have overlapping MIME types).

[fallaciousreasoning]

But some will want us to split to separate URLs on their behalf. Consider an office app that wants to load documents, spreadsheets and presentations at a dedicated URL for each (which loads a completely different codebase). How would such an app work if we gave them only one endpoint?

Hmmm. You're right, this would break that :/

Perhaps they could open files at "/open" which then redirects to the doc, sheet or slide URL, but is it going to be possible to pass a file handle through a redirect?

Almost certainly not.

I think the easiest thing is to just keep things the way they were, but leave the question of multiple file types mapping onto different handlers unresolved, by saying if multiple handlers can handle a particular file, the user agent can choose one arbitrarily (i.e., don't have overlapping MIME types).

Let's discuss this offline. Figuring out the mimetypes for files is non-trivial (we have to talk to the OS) and asynchronous (we have to do IO), so it's a scary thing to depend on before starting the app.

I can't speak to other user agents, but in Chromium this would likely require some not-insignificant changes to our launch process.

[evanstade]

The spec goes into details about how this is calculated.