Why is the API shape different to share target?

[jakearchibald]

It seems like there'll be a ton of cross-over between this feature and share target. In fact, I can't think of cases where you'd want one, but not the other.

I was sad to see that I'd need to set up a significantly different code path for this vs share target.

Would it be possible to converge on one API pattern (either both use POST, or both use launchQueue)?

[tomayac]

Related: w3c/web-share-target#84. I wish we would align on using launchQueue.

[jakearchibald]

Yah, converging on launchQueue would be my preference. If file-handling isn't going to add POST support, then the POST method in share target should be deprecated.

It might also be worth considering a manifest entry that controls both file-handling and share-target at once. It seems like you'd always want both.

[dway123]

I'm not too certain about the history here, but it looks like there was already some discussion in 2019 in w3c/web-share-target#84, with the conclusion being to switch to align on using launchQueue. I'll cc @mgiuca in case there's more thoughts, but I'm not sure if there's anything actionable in this repo if we hope to align on using launchQueue (which file-handling already uses).

[jakearchibald]

It'd be good to add it to the explainer. It currently mentions that share-target is different but it doesn't explain why.

Although, there's a further question of whether these things should be separate features at all.

[fallaciousreasoning]

I tend to agree that the launchQueue is a nicer API (admittedly, I'm biased), but I think there are valid reasons for WebShareTarget to use POST requests: It's a much smaller API surface to implement, and it means sites don't require JavaScript to support the API (though I'm unsure how common that will be).

That said, the POST model definitely feels pretty unergonomic when you do want to handle things in JavaScript (I vaguely remember having to set up broadcast listeners to make sure the page is ready to receive the shared data).

I also recall there being some discussion about the shape of the entry in the WebAppManifest, and why they aren't more similar (see #2 and #7).

I think #7 also includes some of the reasoning that caused us to diverge from the WebShareTarget API in the first place.

[fallaciousreasoning]

Although, there's a further question of whether these things should be separate features at all.

I think this was raised in #2 (comment) and our consensus at the time was that some apps might only be interested in one or the other (and that sharing and file handling are different use cases), though it's quite possible things have changed, especially now the File System stuff is further along.

Note: I don't work on this any more, so take everything I say with a large spoonful of salt 😄

[jakearchibald]

Even if they need to be seperate, it should be easy to use them together. As in, same manifest structure, and same way to access the file(s).

[mgiuca]

So I think I explained my original reasoning for this on w3c/web-share-target#84. There were good reasons for it (this was deliberate design, not an accident), but I think in hindsight I do agree with Jake's opinion on both here and that bug: we should change Share Target to allow for a launchQueue-based event containing the data dump in a format accessible to JS, instead of POST.

I disagree with deprecating POST; we should just add it as a third option (e.g., the method can be "GET", "POST", or a third pseudo-method, "EVENT" or similar).

We won't change File Handling to match Share Target (POST doesn't make sense for file handling since we need a file handle). So I'll close this issue; w3c/web-share-target#84 tracks this in Share Target.

Coincidentally, we were just discussing a new need for this today: to integrate Share Target with Declarative Link Capturing (which in its current form would not be able to navigate to a new URL and preserve the POST request data).

Historical / Explanatory Note

The reason why Share Target and File Handlers differ is because they represent two fundamentally different concepts.

• Share Target represents a one-way ingestion of data from a sender. A copy of the data is being sent into the receiving site.
• File Handling represents the opening of a reference to a file on disk (in a real or virtual file system), which can be read in random access order, and possibly written back to.

In simple terms, Share Target is "pass by value" and File Handling is "pass by reference".

Share Target is conceptually the same as a form submission, only the data comes from another app rather than from an HTML form. That's why it was originally designed (pre file sharing) to put the data in the URL, just like a GET form submission. It was a natural extension to make a POST request when sharing a file. There's a 1:1 analogy to form submissions. I do understand (based on our discussions in w3c/web-share-target#84) that this isn't entirely satisfactory, given that there is no JavaScript access to a POST request's body, requiring developers to bend over backwards if they want to get the POST data in JavaScript, rather than have it sent to their server, which most of these apps will want to do. But having non-file data sent in a GET request while file data is not able to be sent in a corresponding POST request would feel weird and incomplete.

File Handling is nothing like this. Since we aren't making a copy of the file, the site actually needs to have a File object in the JavaScript context, to be able to seek, read and write bytes of the file at will. This is conceptually incompatible with putting the data in an HTTP request.

So that's why they are different. But I agree that we should add a third option to Share Target to allow developers to access the share data in a JavaScript object, just like File Handling, and we should design that API as close as possible to File Handling.

[jakearchibald]

Thank you for pointing out the conceptual differences between share target & file handling. Maybe put it in the explainer, or link to your comment?

Fwiw, although I found the POST method of share target cumbersome to use, using POST did make sense in a lot of ways. But yeah, it's more important that these APIs play together well, because I imagine most apps won't distinguish between the two, or if they do, the differences will be minor.