IDL proposal: createAnchor or addAnchor. destroyAnchor or removeAnchor

[judax]

Just wanted to capture some thoughts on the API ergonomics and identifiers for method names. Should we use create or add, destroy or remove. Native SDKs don't seem to agree on these names either:

ARKit: addAnchor and removeAnchor
ARCore: createAnchor and detach

Of course, more names could be proposed like XRAnchor.destroy/remove instead of XRSession.removeAnchor/destroyAnchor.

[blairmacintyre]

I'm unsure; what's more webby? 😄

My initial reaction is create/destroy; add/remove makes sense; I understand where "detach" might come from, but as a dev I'd think "ok, I've detached it from the world ... does it still exist? Do I need to destroy it too?" since the other one is "create"

[thetuvix]

In Windows Mixed Reality, apps don't "remove" or "detach" free-space anchors, they simply create them and then let them get ref-counted away when they will no longer be needed.

Can you elaborate on the benefit to an app of "detaching" an anchor without destroying it? I suspect that part of this difference may come from overloading of the term "anchor", as discussed in #4, to represent not just arbitrary free-space anchors that apps create themselves, but also detected environmental features, such as planes and meshes - in that case, an app would (for example) never destroy a detected plane, though it may choose not to reason about it once the user has set up their experience on some other plane. Perhaps then, "detach" would be a concept specifically suited to detected world geometry in particular?

[bialpio]

In the current approach to the API, anchors are exclusively poses that are supposed to be tracked by the underlying system, and they get created only if the application requests them (i.e. plane is not an anchor). With that in mind, I have decided to go with createAnchor and detach(), but I'm not married to those names. The rationale is that anchors have 2 entities that control their lifetime - the underlying system and the application, and I think we should not rely on GC to clean up anchors that the application no longer wishes to track (relevant TAG design principle). I'm closing the issue since there was no activity on it for over a year, please open a new one if you disagree with naming / current API approach.

[thetuvix]

Agreed on having an explicit method for destroying an anchor synchronously. However, I also agree with @blairmacintyre that the name detach() implies to me that this newly-detached object will live in on some meaningful unattached way, when in fact there's no longer anything meaningful you can do with that anchor.

I wonder if destroy(), drop(), forget() or simply stopTracking() (to align with trackedAnchors) makes it more clear when you'd call this method: when you're no longer interested at all in that anchor.

I'll make a specific issue for bikeshedding detach() so those with more web API experience than me can call out similar cases in other web APIs.