Re: [w3ctag/design-reviews] Web Share Target API (#221)

@ewilligers: I think it's best to not post uncommitted versions of the spec to personal GitHub pages, since the versioning can get confusing (it's unstable since at any time, it reflects an unknown revision of an unknown branch).

The latest pull request is WICG/web-share-target#40, with a [preview here](https://pr-preview.s3.amazonaws.com/ewilligers/web-share-target/pull/40.html) including the big red disclaimer that this is a preview. It has gone through several rounds of code review since the document @dbaron is talking about (including addressing several of the concerns you raised). But it doesn't include the files part. Eric, perhaps you could create PRs for the "files" versions of these specs and then link to the Preview page instead of to your GitHub?

Note that we aren't planning to roll file sharing into the first version of Web Share Target. We're just thinking about it so we have a good model to extend into. The initial version of WST will more or less look like the above preview.

> It would probably be useful to say what a share consists of.

The new version addresses this.

> The definitions of the app manifest structure contain a bunch of normative "MUST" requirements that seem to be normative requirements on developers.

The new version addresses this. Specifically, the "MUST" requirement on the "action" member has been removed, since it was effectively an informative note. (Processing steps elsewhere say exactly what happens in this case.) I agree, that "MUST" should be reserved for conformance requirements on the processor (the user agent), not the content (the document); there isn't anything that content "MUST" do; rather, the standard describes how the processor handles all inputs.

> I was curious why the canShare function exists given that what it does seems to be rather trivial -- or if it's intended to be extended to something more interesting in the future, whether it should return a Promise.

This was added in Eric's (not yet committed) file sharing version, as a way of allowing for feature detection of the files feature. See a long discussion on heycam/webidl#107. Without it, you wouldn't be able to know whether you're going to be able to share a file without actually trying it. This is a very rough sketch at this stage. It probably should return a Promise.

> I'm a little curious about the use of FileList given that the type's definition says that it's "at risk". Does that statement of being "at risk" need to be revisited?

This is something we're actively talking about with the Chrome storage team who are trying to build on those file specs, and considering whether to try to resuscitate them or build something new.

In summary, let's not get too caught up on the file sharing details of Eric's private branch. We are not launching those features any time soon (in Chrome) and do not plan to land them in the spec soon either. We just want to make sure there is a reasonable model to expand into file sharing territory later.

We want the TAG review to focus on the title/text/URL share target which is currently in [preview](https://pr-preview.s3.amazonaws.com/ewilligers/web-share-target/pull/40.html) but will hopefully soon land in the [WICG draft](http://wicg.github.io/web-share-target).

-- 
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/221#issuecomment-400153304