Remove XRSessionCreationOptions #566
Conversation
As described in #542, this switches `requestSession` to a "primary type + options bag" pattern. However, since the dictionary only had a single key after outputContext was moved this change ends up removing the XRSessionCreationOptions dictionary entirely in favor of just passing in the type enum directly. In the future if additional options *are* needed for `requestSession`, the expected pattern would be: ``` navigator.xr.requestSession('immersive-vr', { option: value }); ```
|
I would like to suggest that we consider moving forward with https://github.com/immersive-web/geo-alignment and use this as an example of possible options. |
|
|
||
| ```js | ||
| function beginImmersiveSession() { | ||
| xrDevice.requestSession({ immersive: true, requiredReferenceSpaceType:'unbounded' }) |
There was a problem hiding this comment.
So this sample code made it into the explainer, but never made its way into the spec because there was confusion about the overall permissions/features model. While we are working through the final shape of that design (oh, John..... pokepokepoke) can we at least file an issue to cover adding this functionality back in once that's complete?
There was a problem hiding this comment.
Alternatively, we can leave the options dictionary and put this in it ;)
|
I like the idea of having the 1st parameter (session type) be explicit, but I'd still like to propose that we keep at least one "option" (I suggested |
|
@toji, please correct me if I'm misinterpreting... but you're not saying you think we don't need it. Just simply that we'll leave it off until a specific feature is actually merged into the spec that depends on it. |
|
Part of my motivation is that I suspect (we’ll, know) it will end up getting used, as people experiment with “next version” or “proposed” features. I expect I’ll put a bunch of things behind prefs (rather than just expose them) in the WebXR Viewer after moving it over to the “real” spec, for example. So I’ll being using this immediately. This, I’d prefer to have at least the name and format of the object defined if we’ll be adding it. |
|
@blairmacintyre The format of the object will almost certainly be a dictionary since that's the general pattern on the web and as such seems like a safe assumption. (And as far as I'm aware, the idl type name shouldn't matter). That said, I do understand your concern. And my suspicion is that we're going to have something that proves the pattern before we hit CR, but I'm hesitant to put it in now so that we don't create a breaking change if we're wrong. Hence, my suggestion to file an issue against CR to enable the extensibility without holding up this PR. WDYT? |
|
Sounds reasonable to me, I'm not sure what to put in an issue. I've been pushing for geo-orientation, for example, for a while; we have had it sitting in a repo (github.com/immersive-web/geo-orientation) for 7 months with no movement. The current proposal would need a little bit of work, may as well wait till after CR so we have a defined API to work against. |
|
Filed #591. Nell confirmed offline that she's comfortable merging this once that issue was filed, so doing so now. |
As described in #542, this switches
requestSessionto a "primary typeplus options bag" pattern. However, since the dictionary only had a single
key after outputContext was moved this change ends up removing the
XRSessionCreationOptionsdictionary entirely in favor of just passing inthe type enum directly.
In the future if additional options are needed for
requestSession,the expected pattern would be: