search

immersive-web / anchors

https://immersive-web.github.io/anchors/
Other
50 stars 20 forks source link

Tighten up spec text around native origins #49

Open Manishearth opened 4 years ago

Manishearth commented 4 years ago

Fixes https://github.com/immersive-web/anchors/issues/46

This PR:

:boom: Error: 500 Internal Server Error :boom:

PR Preview failed to build. (Last tried on Jan 15, 2021, 4:35 AM UTC).

More PR Preview relies on a number of web services to run. There seems to be an issue with the following one: :rotating_light: [CSS Spec Preprocessor](https://api.csswg.org/bikeshed/) - CSS Spec Preprocessor is the web service used to build Bikeshed specs. :link: [Related URL](https://api.csswg.org/bikeshed/?url=https%3A%2F%2Fraw.githubusercontent.com%2FManishearth%2Fanchors%2F49da62c0a31b10b944e81cf81c7d694d762a022d%2Findex.bs&force=1&md-warning=not%20ready) _If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please [file an issue](https://github.com/tobie/pr-preview/issues/new?title=Error%20not%20surfaced%20properly&body=See%20immersive-web/anchors%2349.)._
Manishearth commented 4 years ago

I've rebased and updated things a little bit.

Ultimately, one of my initial approaches to defining native origins was closer to how you describe it. However, if you want to spec native origins as magical objects that have their own semantics, it's significantly more verbose, since you end up needing to define multiple "types" of native origins, including all their references to the objects they track, and we didn't end up going that way.

It is easier to instead define native origin as a field that the parent object can attach semantics to. This means that copying them around won't work, but you can still query what its value was at a given time. It might be worth specifying this clearer in the core spec.

bialpio commented 4 years ago

Thanks for going through this, I've added some comments - LMK if I'm missing something.

(...) it's significantly more verbose, since you end up needing to define multiple "types" of native origins,

I was trying to get away with it by saying that the device is supposed to provide an API that is something like getPose(origin_1, origin_2, time) & it's up to the device to do the right thing and track the native origins appropriately depending on what they are supposed to represent.

In the end, as long as we are able to express what we need in a cross-compat way, it should not matter that much which route we take here. Expect to be added to future PRs related to native origins, I feel that I do not have a good intuition about them yet. :)