Interoperability and compatibility - browser vendors & web developers support

[bialpio]

This should sound familiar:
I'm currently preparing to send out an Intent to Ship for WebXR Hit Test Module so I'd like to poll for other vendors' support for the module. @thetuvix, @Manishearth, @grorg, @rcabanier - can you share your opinion? I'm aware of 2 outstanding issues that we should agree on (#66 & #67) prior to sending an I2S - we're currently planning on marking the concept of entityTypes as unstable / at risk and not including it in the initial version of the spec (as mentioned in issue #66).

Web developers' opinion about this module is also welcome!

[Manishearth]

Servo is hoping to prototype it for the Hololens, but it's going to take a bit of time. We're hoping to find any rough edges for headworn devices since this API so far has mostly been tested with handheld as I understand it.

cc @kearwood for Gecko-based Firefox Reality.

[mounirlamouri]

@Manishearth to clarify, the API as-is, without the entityTypes parts, looks good to you modulo any unforeseen issues with headsets?

[Manishearth]

Yes, to me, personally (not speaking on behalf of all Mozilla people in the WG), I think the API design is good, ignoring the entityTypes stuff. I'm a bit concerned that there are unforseen issues with headsets, but optimistic that they won't be major.

[thetuvix]

The core non-transient hit-test spec looks good to me, modulo the ongoing entityTypes discussions. I'm with @Manishearth in hoping we get to an initial implementation on a headset UA in time to squeeze out any lurking API issues there.

For the recently merged transient hit test PR, the design seems like it holds together at first glance. The primary unfortunate aspect to me there is that we'd be introducing methods like requestHitTestSourceForTransientInput that have ...TransientInput in the name. Transient input is a concept defined in the core WebXR spec, but the term transient never appears in the actual API surface anywhere yet. It feels odd as someone approaching the hit-test API to only encounter the term TransientInput here.

It seems worth some bikeshedding to see if we can align those "transient" member names closer to the core API somehow. Another option would be to tweak the design to more directly reference core API members. A random idea that comes to mind: switching the method to requestHitTestSourceForInputProfile to build on the profiles list that already manifests in the core API surface, returning hits whether the specified profile is transient or not.

[Manishearth]

A random idea that comes to mind: switching the method to requestHitTestSourceForInputProfile to build on the profiles list that already manifests in the core API surface, returning hits whether the specified profile is transient or not.

I'd kinda prefer if the transient API was only used for transient inputs; it doesn't seem great to have two ways of doing the same thing for non-transient inputs, and furthermore it only works with the target ray space, not the grip space. I don't hold this opinion strongly.

That said I agree that the naming is kinda weird.