W3C home > Mailing lists > Public > public-device-apis-log@w3.org > May 2017

Re: [magnetometer] Add RawMagnetometer, for uncalibrated readings.

From: Rick Waldron via GitHub <sysbot+gh@w3.org>
Date: Thu, 11 May 2017 20:37:38 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-300909993-1494535056-sysbot+gh@w3.org>

@tobie

> The right question to ask would be whether either API designs help surface useful information to developers, in a way that lowers cognitive load, makes them understand the overall system better, and thus be more effective. Or does it instead saw confusion.

I absolutely agree with position here. 



> Does it make sense to turn an API that's designed to help build experimental VR features into a full blown global variable, on par with orientation sensors or geolocation?

My opinion would be: no.


> Or on the contrary does it make sense to hide it as an obscure option of an existing API?

Edge cases deserve edge exposure. Making the least common use case available, via some option setting is perfectly acceptable to practioners.


@kenchris

> Why not an option new Magnetomer({ counteractHardIronDistortion: false })
>
> It is really a countermeasure - which is also the reason why people want to turn it off, because it might interfer with what else they are doing, and show similarly to a metal button being pressed.

This would be ideal (as @tobie previously suggested)



@anssiko


> This is a very valid point. I'm in the school of make the common use case easy to implement for the web developer, while make more advanced use cases possible.


Yes, absolutely. This is definitely the motivation behind the previous suggestions by @tobie, @kenchris and myself (https://github.com/w3c/magnetometer/issues/16)


@kenchris

> With the Magnetometer the "uncalibrated" one is most likely not what you want and it is more like an option, like it is adding some anti-aliasing to a rendered scene. It is not a whole new thing, but a slight modification.

I agree with this description, and the conclusion you draw immediately afterward.


@anssiko

> The proposal from @kenchris is to rename the current Magnetometer to GeomagneticFieldSensor and the proposed UncalibratedMagnetometer to Magnetometer.

I could get behind this. I've made no secret that I utterly despise the use use of "Sensor" as some kind of class naming suffix, and would definitely prefer `GeomagneticField`. 



@alexshalamov

> ` if (sensor instanceof UncalibratedManetometer) { `

No argument for any API design in JavaScript should ever include a point that's predicated on `instanceof`. `instanceof` is a liar. 




@anssiko 

> I sensed emerging consensus so I merged this PR as a precaution before we reach the 100th comment in this PR. Thanks all for flying with us!


I didn't sense that at all, considering `UncalibratedMagnetometer` is absolutely not where the conversation was at when you merged this. 

-- 
GitHub Notification of comment by rwaldron
Please view or discuss this issue at https://github.com/w3c/magnetometer/pull/21#issuecomment-300909993 using your GitHub account
Received on Thursday, 11 May 2017 20:37:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 12:18:53 UTC