Consider primary type plus options bag pattern in request methods

[ddorwin]

XR.requestSession() and XRSession.requestReferenceSpace() both take a single options parameter. In many/most cases, only a single primary value from the options needs to be specified. It may be better to instead specify that primary value separately followed by an optional options parameter. This may both simplify the current API and allow for more flexibility for future extension.

Consider:

• The pair of methods in the XR interface are intended to be used together but do not share parameter types:
  Promise<void> supportsSessionMode(XRSessionMode mode);
Promise<XRSession> requestSession(optional XRSessionCreationOptions parameters);
• XRReferenceSpaceOptions only contains a type and subtype.
  • These could be combined (Combine XRStationaryReferenceSpaceSubtype into XRReferenceSpaceType #514), which would make the options parameter unnecessary while allowing one to be added in the future if necessary.
• IDL methods can accept different types in the same parameter slot (i.e., https://heycam.github.io/webidl/#idl-union). If the primary value is a separate parameter, subsequent parameters can be different types rather than needing to have a union of all possible values used for any primary mode/type.

With that in mind, the two methods might be changed as follows:

• Promise<XRSession> requestSession(XRSessionMode mode, optional XRSessionCreationOptions options);
  • Note that one argument is now required. This is a minor part of the change, but it seems reasonable to expect the caller to specify the mode they want just as they do for supportsSessionMode().
• Promise<XRReferenceSpace> requestReferenceSpace(XRReferenceSpaceType type);
  • This assumes the suggestion in Combine XRStationaryReferenceSpaceSubtype into XRReferenceSpaceType #514 is made. If not, some sort of options parameter would be added.

[blairmacintyre]

How do you feel about requestSession succeeding but returning a session with a different mode?

I'm thinking about the case where a device supports both ar and vr, so supportsSessionMode returns true for both. Then the UI presents the user with a choice, and they say they only way ar when the app asks for vr ...

If requestSession fails, the app may simply give up and just assume the user refused (or couldn't) to XR.

If requestSession succeeds, the app will need to look and notice that it's in a different mode.

[NellWaliczek]

A device should support VR if it supports AR, so that case shouldn't happen. Perhaps that's underspecified, though.

[ddorwin]

@blairmacintyre, I think that would be unexpected unless the definition and shape of the method are changed. That seems like a separate discussion, though.

[cwilso]

Note this would change #513 as well (if, as @blairmacintyre suggested, you returned a session with a different mode).

[toji]

Issue is partially addressed now, as #566 landed and changed requestSession to the primary + property bag model. Still need to determine if we're going to address requestReferenceSpace in the same way.