Is there a better term than "TransientInput" for method names?

[thetuvix]

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.

Originally posted by @thetuvix in #74 (comment)

[thetuvix]

@Manishearth's comment from this discussion in #74:

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.

[bialpio]

I agree - the naming is awkward now, but I did not find a better alternative that would send a sufficiently strong signal that this flavor of hit test is supposed to be used only in a fairly specific case. Keeping this constraint in mind, is there a better-suited name?

(...) it doesn't seem great to have two ways of doing the same thing for non-transient inputs (...)

Yeah, I'd like to keep the responsibilities of those 2 methods separate, especially given that the main reason behind creating this variant was to close the gaps that the non-transient variant has w.r.t. transient input.

[toji]

/agenda to discuss overall comfort level with the API shape of the transient hit test functionality.