Use of File in ShareData

[plinss]

From the TAG review:

There are other sources of data that users may want to share that aren't necessarily Files, e.g. a Blob taken directly from a media API. We recommend that File is replaced with Blob in ShareData (and possibly rename the dictionary member).

[mkruisselbrink]

Not saying that it wouldn't make sense to support any Blob rather than just File objects, but a File object is really nothing more than a Blob with a name, and a website can easily turn any Blob into a File object (i.e. new File([myblob], 'file name')), so I'm not sure how limiting the API this to File objects limits this to what data can be shared.

[plinss]

What's the file name of a Blob pulled from a camera? Why should the web app have to do this extra step? If the API accepts a Blob the web page can send a File as well, the browser is free to check for the presence of the name attribute and use it, but shouldn't require it.

If the underlying OS API requires a file name, the UA can synthesize one rather than putting the burden on the web developer, which would also produce inconsistent results.

[ewilligers]

Changing files to be a sequence of blobs seems reasonable and trivial, if an implementation can easily determine that a blob is actually a file.

[marcoscaceres]

We could make it typedef (Blob or File) ShareableObject;... best of both worlds :)

[saschanaz]

File is a sub-interface of Blob so no need for a union.

[marcoscaceres]

Oh yes, good point @saschanaz. However, would we lose the File class's attributes (e.g., filename) by casting it to blob via the IDL layer? 🤔 Would we use an overload instead?

[marcoscaceres]

Actually, ignore the overload question there... we probably want something that can handle: {files: [blob, file, blob, file] }

[marcoscaceres]

On reflection, it's just as easy and probably better just to convert a blob into a file via the constructor. Closing.

[marcoscaceres]

Sent request to TAG to close issue on their tracker https://lists.w3.org/Archives/Public/www-tag/2022Aug/0000.html