See also: IRC log
<trackbot> Date: 01 November 2011
<matt> Meeting: Geolocation F2F day 2
<matt> scribe:matt
lbolstad: We added use case, closing issue-79, but still have the transformations issue-81.
... That will be published Tuesday or Thursday next week.
... Anne will be here at 10am to talk.
ISSUE-95?
<trackbot> ISSUE-95 -- Should we separate out compass heading? -- open
<trackbot> http://www.w3.org/2008/geolocation/track/issues/95
ISSUE-100?
<trackbot> ISSUE-100 -- Figure out how to send initial event to new listeners -- open
<trackbot> http://www.w3.org/2008/geolocation/track/issues/100
lbolstad: Issue-95, we've had discussion about the compass heading. It's currently possible to calculate from the values via a matrix calculation. Dean Jackson implemented separate properties for it in webkit
<lbolstad> Apple's implementation: http://developer.apple.com/library/safari/#documentation/SafariDOMAdditions/Reference/DeviceOrientationEventClassRef/DeviceOrientationEvent/DeviceOrientationEvent.html
steveblock: The difference is that the compass is just alpha, but not gyro.
dougt: They teased apart the different sensors, while we combined them.
... The absolute flag?
steveblock: No, that tells you it's an absolute value not which sensor it is coming from.
andreip: What do they do with alpha then?
steveblock: I believe this is an addition.
<lbolstad> http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0015.html
steveblock: This is the case where the guy jumps off a cliff. He didn't want the alpha data to be clunky. So, as a result they use only gyro data for it, it'll drift, but be high frequency. They'll use the compass for the webkit compass properties, which is low frequency.
... We believed we could combine these to be best.
... I believe the presentation yesterday is pretty conclusive proof.
dougt: If you wanted to mix in JavaScript to produce the stuff we saw yesterday, you can't do that.
steveblock: I think Dean's argument is that only the app which knows what the signal is being used for, can make the right choices.
dougt: We wanted to solve the 80% case instead.
steveblock: We decided at last f2f that we would get back to Dean with an example that couldn't be done.
matt: Is there harm to having access to the compass the way they say?
steveblock: No harm, just that we aimed not to do a device API, but instead a higher level of data.
andreip: But we say things like device acceleration are from accelerometer.
steveblock: I don't think we do.
lbolstad: What's the resolution? Will this stuff go in Chrome?
andreip: No, it's not in WebKit I think, it's Safari I think.
... Is it going into Opera?
lbolstad: We had the AR meeting last week, and we thought it would be hard to figure out direction facing, and they liked this.
steveblock: I could be wrong, but I think there's no difference between alpha and compass, just the source.
ernesto_jimenez: compass heading is more clear than alpha/gamma/beta.
steveblock: As far as I understand it, you don't get that from the webkit version. It talks about which way it is pointing, but not which direction.
... When Dean was talking about it, he was talking about a different source, didn't seem to be indicating a different transformation.
<lbolstad writes some HTML and script to test webkit compass>
steveblock: Seems to be a vector out the back of the screen -- wait, no, pointing it down does something right too? I don't know what they're doing.
ernesto_jimenez: Perhaps this isn't absolute? And it's using compass and gyro.
steveblock: But what is it measuring? It doesn't mean anything.
<group goes outside to figure out where north is>
steveblock: I suspect compass heading in webkit doesn't match alpha at all.
<lbolstad> Test page: http://people.opera.com/lbolstad/heading.html
<lbolstad> showing that webkitCompassHeading gives the compass heading of the "camera lense" if the device is held in "portrait" position with the user facing the screen
lbolstad: So you would have to do the transformation on the alpha to get whatever it is that webkit compass does?
steveblock: No, I think it's an entirely different transformation.
lbolstad: When I'm writing an AR app, I want to be able to calculate where the camera lens is pointing.
... With webkit compass I could get portrait mode to do that but landscape was something else entirely.
steveblock: So, not the same transformation.
lbolstad: Are we fine with this math example showing the matrix calculation?
steveblock: I think so, because if you're writing an AR app you're already doing lots of math.
... We could choose the axes so that the alpha vector fell out when lying on a table for instance, but we could have chosen them so it was the back of the camera that fell out for AR type apps.
lbolstad: Do we have consensus that we don't want to add these to the spec?
steveblock: It's hard to say, as we don't know what it is yet.
anne: Adding event listeners must be side effect free and yours is not.
steveblock: Why do they have to be side effect free?
anne: That's what it is.
dougt: Can you change it?
anne: No. Why would we?
dougt: Easy of use.
... The way we worked around this is as soon as you add an eventlistner you get an event. Truth is we get accelerometer events all the time so it's not a big deal if it didn't. But if the device is sitting still you never get an event.
anne: The architecture of the DOM makes events and adding listeners orthogonal. If you start entangling them, you violate DOM principles.
... Just use a callback.
dougt: But they we have to do two things as developers.
andreip: We had complaints about new geo not using events.
anne: Why?
dougt: Because we understand the plumbing for events and can do it easily.
anne: All sorts of call back APIs.
dougt: Yeah, but we see huge differences between the amount of time and bugs and such in callbacks compared to new events. We've got data on it.
anne: An alternative could be an event stream.
steveblock: I completely understand the conceptual idea of separation. But, surely the user will have a library that then ends up wrapping the two calls into one and making the user wonder why they have to care about the esoteric stuff at all.
anne: My main problem is that implementers understand the principles.
... And now you want to change it and it seems wrong to violate those.
andreip: This is really a major change for us.
... You have a spec about adding these things, why not add to it that other specs can add to it.
anne: But it'd be awkward.
... You think your designs are better than all of the design decisions before it?
andreip: This is a big difference.
anne: It's just like online!
dougt: No, that's synchronous and we know it. This one you have to fire up hardware.
... We need an asynch API.
anne: The callback could be unknown first.
andreip: What's that mean? What do they do?
... Jiggle it?
anne: That's what they have to do with maps.
andreip: It ends up seeming hacky.
anne: The other way seems like a hack too, that you have to fire up hardware for the first event?
dougt: So, wait, you're saying if you add an event listener, there should be no fallout, no hardware turned up?
anne: But you don't even know if it's your event or one synthetically dispatched by your app.
... You only check the type, not the interface of the event.
... The semantics are in the type name, but should be in the event object.
... You could do init and state change.
andreip: It's terrible though.
anne: If it's terrible then you should change it there. Can't do it different everywhere.
andreip: We should copy things that are obviously broken?
anne: If it's obviously broken, then fix it.
dougt: You're arguing for purity, which is noble --
anne: It's not just that, but --
andreip: So, you should turn the hardware on when?
dougt: We've shipped to half a billion users, iPhone has shipped to millions and millions. We want to standardize what browsers are doing today.
anne: Ship it, we'll object, someone will overrule it and we'll be fine.
... You shouldn't just do it, but if you think your stuff is better than what was there before, then you should fix it everywhere.
lbolstad: There are other hardware based events, we might be the first, but they'll have the same issue.
andreip: Battery had the same issue too. But that one you can have a synchronous getter.
dougt: You can, but you might not be able to. I don't know that you can always get the battery status instantly.
andreip: You're telling us to reuse existing patterns, but also telling us to use callbacks, which aren't established.
anne: Callbacks are an established pattern. They are used all over. Or do what message channel does.
andreip: Do you really think that's a good example?
... Most people don't see a difference between the two events.
... You think that developers know that one has a side effect and the other doesn't?
anne: Yes.
dougt: I don't believe that at all.
anne: Then don't follow it.
dougt: I think if we don't we'll need you to say that other specs may do it this other way.
anne: I don't think it's fine that addeventlistener has side effects.
... Why is yours better than message channel?
dougt: Imagine registering for DeviceOrientation and not getting events. And having to know OnDeviceOrientation.
... It's weird to say "Tell me when this changes" and it doesn't power enough of the subsystem to do that? That's sort of a broken pattern.
... I ask the browser "tell me when the orientation changes"
anne: You're saying the initial value though, not change!
dougt: OK, separate them out. Let's talk about turning things on.
... I say addEventListener DeviceOrientation, you say you don't want us spinning up gyroscope.
anne: Correct.
dougt: I disagree on that fundamentally. If I ask a system to tell me when there is a change, it seems broken that it wouldn't spin up enough of the system to tell me of that change, right?
anne: That's an implementation detail.
dougt: A lot of this is close to the metal.
... We need to know how it's going to work from the spec and the implementation point of view.
anne: You don't need to define that.
dougt: Yes, we do need to know if the accelerometer is working.
anne: The spec assumes that the system always knows and tells when there is a change.
... Implementations can optimize that, they might not dispatch events if there are no listeners, etc.
dougt: Sounds like you're arguing against your own point.
anne: Implementations can optimize, sure.
steveblock: Even if there are side effects.
anne: Yes.
... If it's black box observable, sure.
dougt: OK, so no sensors on, get a call to addeventlistener, we can spin it up then?
anne: Yes.
dougt: So the only thing we're arguing about is the first event?
anne: Right.
steveblock: But in the blackbox knows all scenario, then it fires on a change, can we define that event to be getting the first value.
anne: If it's not moving and it's not changing then the event gets dispatched. There is no beginning.
dougt: We could fire periodically. 60hz or something and send events all the time.
... So, you don't get an initial event on addEventListener, but you would get it within a few hundred millis.
... And that would fix.
anne: Some specs do things like every X mills or bytes received.
dougt: We get lots of firings, but don't send them all to script. We could say it gets dispatched every X millis or something.
anne: Yes, if you did that, it follows the model.
dougt: So, addEventListener then spins up hardware --
anne: Not in the spec.
dougt: But in practice. All browser folks will spin up hardware and that request will come in. We don't even have to say there is a timer right?
... Can we say it'll be called every N seconds?
anne: You say that with the event and not the listener.
... You say queue a task every n millis.
andreip: We could do it without periodic.
anne: Yes, it has to be because of the side effect.
andreip: So, it's a side effect if it's once, but not periodic?
anne: Yes.
dougt: The system gets to decide when it gets fired. We can decide based on some thing random the frequency.
andreip: Why?
dougt: Just to get around this thing.
andreip: We can fire every x millis from some undefined point in time?
dougt: We have to fire it all the time, it's the implementation that decides this stuff.
steveblock: You mentioned black box observable difference. We currently say "if significant change occurs" -- from outside the blackbox, I can't see the raw data from the sensors, I have no way of knowing if the impl is staying true to that or not.
... If it chose to fire an event in response to addEventListener then you can't tell from the outside that it is true or not. Can't we just do that?
anne: Right, but it's icky from a purity point of view.
steveblock: It solves the common use case for the developer.
anne: If it were done that way, then I'd rather have it just be clear.
dougt: I'd be happy if we could fire a timer at some frequency, leave it up to the UA to fire it or not.
anne: Have you discussed it with Johnny from Mozilla?
dougt: No.
anne: I'd be interested in hearing what he thinks, and some of the other people from Mozilla.
dougt: I could talk to them, they sit right by me. This is shipped and in iPhone.
anne: I don't care about that much.
dougt: To be pragmatic the users are already accustomed to it.
andreip: We get here and have implementers agree, and if it's not in the spec that we agree upon, and we all do it, what is the purpose of the spec.
anne: I agree that we should have the spec be true, but you're breaking 10 years of history on this part.
... It's come up elsewhere.
dougt: Where?
anne: Messaging. Workers and pages.
... That has the exact implications and it was decided side effects were a bad thing.
... onMessage has side effects, it has oneventlistener and then a start.
dougt: That's clumsy right.
... We only added on change stuff because of webkit. Hixie said "do them if they are there", it wasn't assertive to have on handlers for things.
lbolstad: Conclusion?
anne: Don't know. I'm curious what others outside this room are thinking?
dougt: Feel free to talk to them.
<Recap for hixie>
dougt: addEventListener side effects in DeviceOrientation. When we do the add we spin up the hardware. There's a problem if we have a device sitting on a table, the callback never gets called.
... In practice, we're not seeing that. Gecko's filter for instance would pick up vibrations on the table. But, to get around that, we call this callback after a period of time "here's the last piece of data that we had".
Hixie: Within what?
dougt: From the addEventListener call.
... To get around this, we fire an event that isn't really a change event.
steveblock: Even if the hardware is powered up, but not changing, we still fire the event.
dougt: We think we're in agreement that it's fine to turn on power in addEventListener -- the page doesn't know it.
... Should we send that other event?
andreip: We discussed having a synchronous getter, but that would be too expensive.
dougt: Or you could have it and throw, but I don't want to do that.
anne: It's similar in messaging.
steveblock: Let's say the hardware has just fired up -- different from the case of it having already been fired up -- is it acceptable in that case to make the callback when you get the first piece of information? Does that fall under definition of change.
Hixie: We're trying to avoid having addEventListener at the end of the page or the beginning, or in the middle, should have the same effect.
... So the model is that it's always running -- not physically, just in the model -- so when you add an event listener, you're looking for change from that point.
steveblock: You're supposed to fire events when change happens, that side steps the no data scenario as it's always running in the model.
Hixie: Right.
... Do you fire the event again if it stays stationary?
dougt: No, but we discussed a timer to side step this, but we don't need it.
Hixie: If you add a listener once, but then another library adds it, do you get the first event again?
dougt: Every time there is no data and you call addEventlistener.
Hixie: Page starts, addeventlistener, but never gets an event again, then how does another addeventlistner get it's event?
steveblock: We break it a bit, because we fire an event for all of the addeventlsiteners.
Hixie: That's a break then. A year ago, I'd say add a callback handler pattern, but you already shipped, do what you can I guess.
andreip: Do we put this in the spec or not?
steveblock: In practice, the hardware is noisy, so you can't really tell.
... In theory that double addeventlistener would be blackbox detectable, but in practice you wouldn't.
dougt: You could up the filter, but you probably wouldn't want to.
Hixie: We don't to set a precedent.
dougt: I think you're going to run into this a lot.
... As we add more device support, you're going to have the same problems.
Hixie: It's more justifiable for devices, but some of the other cases it's not.
andreip: One way would then be to ignore the problem.
dougt: From a black box perspective you can't tell, but we all know we do.
steveblock: A year ago the advice would have been not to use DOM Events?
Hixie: I would have said use callbacks.
dougt: Ironically we were told DOM events would be the way to do this.
andreip: We had the same discussion in geo too.
dougt: But we had options.
Hixie: Geo seems to do it the right way. Conceptually with events -- not GPS -- you have this thing firing events all the time and you just hook into it. Conceptually, the events are always there, not plugging in and turning things on.
dougt: In practice we are.
Hixie: Yes.
dougt: I imagine the precedent here is going to fall through. Other devices are going to have the same thing.
Hixie: These kind of things I'd say have a callback.
... What models what is closely going on is that you want to be told, the events aren't firing.
dougt: If I were going to bring up new events, I would not want to bring a new callback, I'd want to have events.
Hixie: People who use this use addEventListerner and not on event?
dougt: We did it because others did, but we didn't initially.
andreip: You told us to add them.
Hixie: Setting an attribute is not so bad to have side effects.
dougt: I disagree with that violently. To a Web developer they are the same.
andreip: Most Web developers really don't know that.
Hixie: In this case it's a very subtle difference.
... With message ports we enable the port on the on message, rather than start.
... With addEventListener you might have multiple and you don't know where to start it.
... When you set onMessage the browser automatically calls start. But when you add event you don't.
anne: If there are side effects in oneventlistener then you should have them everywhere.
Hixie: It's going to be firing anyway, but you can't tell.
... How often does this fire?
dougt: Sitting on the table you can't make it stop.
... You cannot tell if you're blackbox testing.
... I think this is somewhat academic, and esoteric, you won't see this in practice.
Hixie: I would put a sentence in the spec where it fires the event.
... It's already a should, and it says "significant", two wiggle words.
... I think that's right for this particular case.
... You could say the event may fire whenever the UA feels like it.
anne: You also need to adopt the event constructors.
Hixie: There's a new syntax for it.
... That sentence is fine, but it will cause people to wince.
... Maybe: "Implementations may also fire the event after they have …" no. "Soon as" is kind of weird. You say "should", but then give a specific time as to when. It's weird.
... "Implementations may also fire the event after spinning up the hardware" --
steveblock: It's more than that because it might be fired up for other addeventlistener.
Hixie: "Implementations may fire the event if they have reason to believe the page does not have sufficiently fresh data"
anne: I don't know, it's pretty icky and clear that it's broken.
Hixie: To people in the room maybe, but I think this is reasonably subtle.
... An event works but I don't think it's great...
dougt: As we get devices, we will have this as precedent though.
Hixie: There's precedents for everything.
... Make it "may also fire"
... And remove initDeviceOrientation and make a constructor.
anne: There's no real text, define an IDL dictionary for the properties and add constructor before the interface, first argument is type, second is dictionary.
Hixie: And defaults. It's really simple.
<dino> ok
<dino> np
<dino> enjoy
<scribe> ACTION: steveblock to add suggested text above to the spec wrt initial event [recorded in http://www.w3.org/2011/11/01-geolocation-irc]
<trackbot> Created ACTION-95 - Add suggested text above to the spec wrt initial event [on Stephen Block - due 2011-11-08].
close ACTION-88
<trackbot> ACTION-88 Send email to www-dom regarding initial event closed
ACTION-89?
<trackbot> ACTION-89 -- Andrei Popescu to follow up with Dean Jackson to get more details on webapps breaking as a result of combining compass and gyro data -- due 2011-09-14 -- OPEN
<trackbot> http://www.w3.org/2008/geolocation/track/actions/89
<lbolstad> scribe: lbolstad
Issue-95?
<trackbot> ISSUE-95 -- Should we separate out compass heading? -- open
<trackbot> http://www.w3.org/2008/geolocation/track/issues/95
<dino> matt: ok
Hi Dean
<dino> hi
We'd like to discuss issue-95
<dino> give me a sec - calling
the question is whether we should add similar properties to webkitCompassHeading/Accuracy to the spec
<matt> ISSUE-95?
<trackbot> ISSUE-95 -- Should we separate out compass heading? -- open
<trackbot> http://www.w3.org/2008/geolocation/track/issues/95
Dean: background for Apple's properties
problem was to make alpha real world accurate
underlying ios/hw has improved recently so it might be easier to expose the compass heading in alpha now...
Action-89?
<trackbot> ACTION-89 -- Andrei Popescu to follow up with Dean Jackson to get more details on webapps breaking as a result of combining compass and gyro data -- due 2011-09-14 -- OPEN
<trackbot> http://www.w3.org/2008/geolocation/track/actions/89
Dean: Mostly internal test apps, need to check
Dean will send an email to the mailing list about Apple's plans to change their implementation in future versions of mobile Safari
Once we have that email we'll close issue-95.
The consensus is that we'll NOT add extra properties for compass heading or accuracy
<dino> To be clear for the minutes - I can't commit to changing our implementation, but of course we want to try to be compliant with the spec. I'll send an email saying that I'm no longer strongly in favour of the compass properties being separate.
ok, thanks Dean
<matt> ACTION-75 due 2011-11-02
<trackbot> ACTION-75 Update address field to RFC mapping and add it to spec due date now 2011-11-02
paper from Layar: http://www.perey.com/ARStandards/[Layar]Mobile_AR_Roadblocks_for_Growth.pdf
so, with the (minor) changes outstanding we're basically ready to go to last call
with DeviceOrientation
We will aim to have the LC working draft ready next week.
Matt will update the status section
For testing we conclude that we'll develop a compass web application, similar to the this one:
http://tripleodeon.com/2011/10/taking-a-new-device-api-for-a-spin
<matt> ACTION: Matt to prepare DeviceOrientation LC for publication [recorded in http://www.w3.org/2011/11/01-geolocation-irc]
<trackbot> Created ACTION-96 - Prepare DeviceOrientation LC for publication [on Matt Womer - due 2011-11-08].
Steve volunteers to implement it!
Other demos we could build on:
http://people.opera.com/richt/release/demos/orientation/artificialhorizon/
http://people.opera.com/richt/release/demos/orientation/level/
http://people.opera.com/richt/release/demos/orientation/basic/orientation_compass.html
Should we do a simultaneous FPWD and LC publication of Geolocation v2?
There are no objections to this among the wg members present, so we hereby decide to do that.
<matt> RESOLUTION: We will publish Geolocation API V2 as FPWD and Last Call next week
<matt> ACTION: Matt to prepare V2 as FPWD and LC for publication [recorded in http://www.w3.org/2011/11/01-geolocation-irc]
<trackbot> Created ACTION-98 - Prepare V2 as FPWD and LC for publication [on Matt Womer - due 2011-11-08].
Should we have another f2f meeting?
Consensus: Yes.
We should have our next meeting after the LC period ends for v2 and DeviceOrientation, some time in February
Doug offers to host the meeting in Mozilla's London office
<steveblock> matt: yt?
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/??/Johnny/ Succeeded: s/Hixie/steveblock/ Found Scribe: matt Inferring ScribeNick: matt Found Scribe: lbolstad Inferring ScribeNick: lbolstad Scribes: matt, lbolstad ScribeNicks: matt, lbolstad Default Present: dcheng3, tpac, +1.408.881.aaaa, dino Present: matt ernesto_jimenez dougt lbolstad steveblock andreip Satoru Found Date: 01 Nov 2011 People with action items: matt steveblock WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]