IRC log of geolocation on 2011-09-07
Timestamps are in UTC.
- 08:39:35 [RRSAgent]
- RRSAgent has joined #geolocation
- 08:39:35 [RRSAgent]
- logging to http://www.w3.org/2011/09/07-geolocation-irc
- 08:39:39 [steveblock]
- steveblock has joined #geolocation
- 08:39:43 [matt]
- Meeting: Geolocation WG F2F 2011 #2
- 08:41:22 [andreip]
- andreip has joined #geolocation
- 08:41:36 [matt]
- Present: Lars_Erik_Bolstad, W_Maslowski, Steve_Block, Andrei_Popescu, Matt_Womer, Diana_Cheng, ??
- 08:45:06 [andreip]
- thanks
- 08:45:19 [matt]
- Scribe: Matt
- 08:45:23 [matt]
- Chair: Lars Erik
- 08:46:11 [ernesto_jimenez]
- ernesto_jimenez has joined #geolocation
- 08:46:13 [matt]
- Topic: Device Orientation
- 08:47:03 [matt]
- -> http://lists.w3.org/Archives/Public/public-geolocation/2011Jun/0059.html Geolocation V2 and backwards compatibility
- 08:47:03 [dougt]
- dougt has joined #geolocation
- 08:47:13 [dougt]
- o/
- 08:47:28 [andreip]
- thanks Matt!
- 08:48:22 [matt]
- steveblock: The idea was to have v2 backwards compatible: a page written for v1 will work in v2.
- 08:48:35 [matt]
- steveblock: We thought about versioning the API, but decided it would be nice not to.
- 08:48:45 [matt]
- steveblock: We thought it would be nice if pages written for v2 would work with v1 as well.
- 08:49:33 [matt]
- steveblock: So, this basically meant three things: 1. making coords optional 2. optional Position.address property and 3. add PositionOptions.requireLatitudeLongitudeAccuracy
- 08:50:15 [matt]
- dougt: I talked about instead perhaps getting back an address object.
- 08:50:29 [matt]
- dougt: On many systems there are two different subsystems, one for location, one for geocoding.
- 08:50:42 [matt]
- dougt: So, you're implementation will have to get the location, then do geocoding.
- 08:51:03 [matt]
- dougt: If it's a watch, if you do the lat/long without the address first, then when the geocoding happens get back the address object.
- 08:51:35 [matt]
- steveblock: That would require an extra round trip, which is likely to not be acceptable to developers.
- 08:51:46 [matt]
- dougt: But geocoding costs more than location typically. This would make it very explicit.
- 08:52:07 [matt]
- andreip: The one round-trip was a requirement for search for instance.
- 08:52:25 [matt]
- steveblock: I think that discussion is orthogonal actually to this.
- 08:52:59 [matt]
- dougt: The server may return long/lat, then a second JS call could return the geocoded address.
- 08:53:17 [matt]
- andreip: How would you know that it's ready?
- 08:53:34 [matt]
- andreip: We only want geocoding when we need it.
- 08:53:44 [matt]
- dougt: Then this would do that.
- 08:53:54 [matt]
- dougt: You would add another flag.
- 08:54:18 [matt]
- steveblock: If we want to return another address block we'd have to have another flag to indicate address.
- 08:54:24 [matt]
- dougt: When would location even be null
- 08:54:41 [matt]
- steveblock: The classic phone example, where they know their address but not lat/lng.
- 08:55:05 [matt]
- andreip: Right now we don't have any implementors that support just civic address.
- 08:55:12 [matt]
- andreip: Do we want to support that?
- 08:55:18 [matt]
- steveblock: I think it makes sense.
- 08:56:06 [matt]
- diana: Was there a requirement that coordinates be optional from the mailing list?
- 08:56:16 [matt]
- steveblock: I don't think so, there was just talk about how to do it in a simple way.
- 08:57:17 [matt]
- [[I think just being able to put my address into my browser would be nice. When I'm at work, it's on a wired network with no GPS, which could be a common use.]]
- 08:57:23 [matt]
- dougt: I don't like the flag, but we don't have another proposal.
- 08:57:41 [matt]
- steveblock: While it's ugly, you can pretend it's not there unless you care about these subtle differences.
- 08:57:47 [matt]
- andreip: I don't like the name, it's way too long.
- 08:57:51 [matt]
- steveblock: Could be something else.
- 08:58:33 [matt]
- Present+ Ernesto_Jimenez
- 08:59:05 [matt]
- dougt: Why wouldn't we just add a flag to positionOptions to say "fetch geocoded info if available"?
- 08:59:26 [matt]
- dougt: Then your implementation can fetch it from cache, or whatever.
- 08:59:38 [matt]
- andreip: What would you do to enable a v1 call?
- 08:59:50 [matt]
- dougt: No, I was thinking a positionOptions property "getGeocodedInfo", and everything else just works the same.
- 09:00:09 [matt]
- dougt: Then impl asks the geocoder, get civic address if you have that flag set.
- 09:00:33 [matt]
- steveblock: Then the phone case of having just address, but not coords.
- 09:00:55 [matt]
- andreip: So you'd get back the v1 object, then call a second api?
- 09:01:05 [matt]
- wmaslowski: ??
- 09:01:33 [matt]
- andreip: The drawback to me is that I have to call a second method and then wonder why it doesn't work, if I forgot to put that option on the position object. I haven't seen APIs work like that.
- 09:01:40 [matt]
- dougt: Android does actually.
- 09:02:25 [matt]
- dougt: So, if this is the best proposal, let's work on that name.
- 09:02:55 [matt]
- dougt: Can we make this requireCoords, and then make --
- 09:03:07 [matt]
- steveblock: This was to make coords optional, but...
- 09:04:05 [andreip]
- :)
- 09:04:24 [andreip]
- name of the flag would be requireCoords
- 09:04:38 [matt]
- steveblock: requireCoords being false would mean you'd have to null check all the coords.
- 09:04:48 [matt]
- dougt: How badly does it break v1?
- 09:04:53 [matt]
- steveblock: I think it's pretty bad.
- 09:04:59 [matt]
- dougt: You just have to test for lat/lng.
- 09:05:54 [matt]
- andreip: That reminds me of one thing in v1: reports of those using the API that we did for writing the IR, we found it's used quite a bit, and we can't break v1.
- 09:07:26 [matt]
- steveblock: I guess we could say something like "enableCompatibilityMode" or something, but I think it's best to be specific.
- 09:08:45 [dougt]
- ^ i was hoping, but i knew it was bad. (fwiw)
- 09:09:14 [matt]
- PROPOSED RESOLUTION: We will use Steve's proposal, but will use requireCoords instead of enableLatitudeLongitutdeAccuracy
- 09:09:21 [matt]
- andreip: Everyone is fine with the IR?
- 09:09:36 [matt]
- [[no objections]]
- 09:09:59 [matt]
- rrsagent, draft minutes
- 09:09:59 [RRSAgent]
- I have made the request to generate http://www.w3.org/2011/09/07-geolocation-minutes.html matt
- 09:10:06 [matt]
- rrsagent, make logs public
- 09:10:36 [matt]
- s/Topic: Device Orientation/Topic: V2 Backwards Compatibility/
- 09:13:05 [matt]
- Topic: Address Object
- 09:13:17 [matt]
- dougt: We shipped with what's in the Editor's spec now.
- 09:13:27 [matt]
- dougt: I would be in favor of building from that.
- 09:13:41 [matt]
- andreip: We spent a lot of time trying to map this to the GeoPRIV stuff.
- 09:14:07 [matt]
- andreip: I believe this is very close to the Microsoft proposal.
- 09:14:19 [matt]
- dougt: This is a subset of other formats and I think it's something others can digest.
- 09:15:04 [matt]
- dougt: We want to be in sync with Contacts API too.
- 09:15:10 [matt]
- andreip: We could take it from the Contacts API.
- 09:15:17 [matt]
- dougt: Or at least import it as a subset.
- 09:15:22 [matt]
- dougt: I just don't understand how this is a new problem.
- 09:15:46 [matt]
- wmaslowski: We introduced two separate formats to do the same thing, that's bad.
- 09:17:24 [matt]
- -> http://portablecontacts.net/draft-spec.html#schema Portable Contacts schema
- 09:17:30 [matt]
- [[group looks at above schema]]
- 09:17:41 [matt]
- dougt: Most of this will map directly.
- 09:18:17 [matt]
- dougt: I don't want to spend two hours talking about the address object. I'd rather say we have a subset and make it extensible and optional. Maybe have a flag for more
- 09:18:37 [matt]
- dougt: The ones I have are: street #, name, city, county, region, country, country code.
- 09:19:24 [matt]
- andreip: If the object is to be compatible with this, then we are.
- 09:19:39 [matt]
- lbolstad: The feedback I got was about the ContactAPI
- 09:20:09 [matt]
- andreip: Can we ask them why?
- 09:20:33 [dougt]
- http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/geolocation/nsIDOMGeoPositionAddress.idl?force=1
- 09:20:38 [matt]
- wmaslowski: They had a long discussion about what to use. To start they had their own, then aligned with ?? and the Portable Contact guys, vCard and OMA.
- 09:20:41 [dougt]
- ^^^ what mozilla shipped
- 09:21:00 [matt]
- wmaslowski: They said Portable Contacts maps most easily to those, so used those.
- 09:21:04 [matt]
- andreip: So, we're fine.
- 09:21:17 [matt]
- wmaslowski: You could have two formats, but alignment would be better.
- 09:21:37 [matt]
- andreip: Given that contacts was to be compatible with this, and theirs is a subset of ours, then it seems ok.
- 09:21:58 [matt]
- dougt: We have a format, it's a subset, but it's bigger than Portable Contacts. Not sure what else we can do.
- 09:22:14 [matt]
- steveblock: We're aiming for something simple.
- 09:22:20 [matt]
- diana: ??
- 09:22:29 [matt]
- dougt: What would we do differently if we sent them something?
- 09:22:38 [matt]
- diana: That we should align with them.
- 09:22:48 [matt]
- andreip: Then we'd have to go back to Geopriv and realign with them.
- 09:22:55 [matt]
- dougt: I don't like looking for reasons not to move forward.
- 09:23:00 [matt]
- dougt: We should tell them what we're doing and why.
- 09:23:04 [matt]
- andreip: I'm happy to do that.
- 09:23:15 [matt]
- andreip: We had the discussion with IETF a year ago, everyone can read thta.
- 09:23:19 [matt]
- s/thta/that/
- 09:24:24 [matt]
- lbolstad: Should we mention this in their last call?
- 09:24:42 [matt]
- dougt: Their contact format is a subset of ours. It's almost straight. They only have four or five fields that map to ours.
- 09:24:57 [matt]
- dougt: I think we pull out the street number, but you can concatenate those two.
- 09:25:47 [matt]
- lbolstad: So we build a website and get an address object, and you want to store it in your address book, then you'd have to map it.
- 09:26:19 [matt]
- andreip: Is streetAddress not the full address making the other contact fields redundant?
- 09:26:27 [matt]
- steveblock: ??
- 09:26:35 [matt]
- andreip: So the only complete way of reading that is from the streetAddress?
- 09:28:41 [matt]
- ernesto_jimenez: I've never done the internationalization of addresses in JavaScript.
- 09:28:56 [matt]
- andreip: Ours is pretty simple though, just mapping fields to fields, not changing the data here.
- 09:29:01 [matt]
- ernesto_jimenez: Except streetAddress
- 09:29:12 [matt]
- ernesto_jimenez: Like family name and given name.
- 09:29:20 [matt]
- andreip: We also have additional information we can use.
- 09:30:18 [matt]
- andreip: We wouldn't be able to generate the streetAddress
- 09:31:58 [matt]
- matt: I think streetAddress is just num, street name, type, rather than full thing, as there's a formatted object. And that object talks about a 'street' property, so I bet streetAddress was renamed from street.
- 09:32:25 [matt]
- -> http://dev.w3.org/2009/dap/contacts/ Editor's Draft
- 09:32:34 [matt]
- wmaslowski: They removed formatted in the latest.
- 09:32:44 [matt]
- andreip: I think we're perfectly fine.
- 09:33:03 [matt]
- lbolstad: We could ask them to align theirs with ours if we care, so the mapping is direct.
- 09:33:18 [matt]
- ernesto_jimenez: It wouldn't be possible as the address format from the device is out of our control.
- 09:33:27 [matt]
- andreip: What you have here is exactly what we have minus the two fields.
- 09:34:01 [matt]
- lbolstad: Do we, as a working group, want to give formal feedback that in order to make this mapping easier, add our two fields?
- 09:34:33 [matt]
- dougt: We should do that.
- 09:36:26 [dougt]
- matt: s/should/could
- 09:36:31 [dougt]
- MoSCoW and all.
- 09:36:36 [lbolstad]
- ACTION: andreip to send feedback to the DAP wg suggesting they align their Address object with ours
- 09:36:37 [trackbot]
- Created ACTION-81 - Send feedback to the DAP wg suggesting they align their Address object with ours [on Andrei Popescu - due 2011-09-14].
- 09:36:38 [matt]
- s/We should/We could/
- 09:37:52 [steveblock]
- ACTION: steveblock update V2 spec with requireCoords and send diff to list
- 09:37:57 [trackbot]
- Created ACTION-82 - Update V2 spec with requireCoords and send diff to list [on Stephen Block - due 2011-09-14].
- 09:38:26 [steveblock]
- ACTION: steveblock update V2 spec with requestAddress and send diff to list
- 09:38:27 [trackbot]
- Created ACTION-83 - Update V2 spec with requestAddress and send diff to list [on Stephen Block - due 2011-09-14].
- 09:38:44 [matt]
- rrsagent, draft minutes
- 09:38:44 [RRSAgent]
- I have made the request to generate http://www.w3.org/2011/09/07-geolocation-minutes.html matt
- 09:40:09 [matt]
- .. enableAccuracy...
- 09:40:16 [matt]
- dougt: Reason it's there isn't privacy.
- 09:40:19 [matt]
- andreip: Right.
- 09:40:41 [matt]
- steveblock: The idea was to maybe use it for wifi for a while, then when you get somewhere pick up higher accuracy.
- 09:41:01 [matt]
- dougt: I'd rather see a JavaScript library built on top of that...
- 09:41:25 [andreip]
- http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0001.html
- 09:41:33 [matt]
- i/enableAccuracy/Topic: Proximity Alarm/
- 09:43:51 [matt]
- lbolstad: The use case on proximity alarm would be something like a store wants to offer a coupon.
- 09:44:06 [matt]
- dougt: How would you build that? It'd be "I'm this far from this location"?
- 09:44:19 [matt]
- andreip: Get the location, calculate the distance.
- 09:44:24 [matt]
- dougt: From where?
- 09:44:48 [matt]
- steveblock: Say a store offers a coupon to popup when you're x distance from the store. You know the store lat/lng and when you get close a coupon pops up.
- 09:45:13 [matt]
- steveblock: I think the idea is to only use say wifi rather than GPS, or cache nearby cell ids, to avoid unnecessary round trips.
- 09:45:22 [matt]
- dougt: All of this is implementable with the current API.
- 09:45:24 [matt]
- steveblock: Not really.
- 09:45:34 [matt]
- steveblock: Not in one request.
- 09:46:12 [wmaslowski]
- wmaslowski has joined #geolocation
- 09:46:23 [matt]
- dougt: Anyone doing this now?
- 09:47:31 [matt]
- matt: I believe from what I've read about iOS 5 that they've got a location based reminders app that is built on APIs that do things like this.
- 09:47:54 [matt]
- steveblock: I think we've agreed that it doesn't add new functionality, but does save power.
- 09:48:24 [matt]
- andreip: You could have lots of proximity alerts and know where you are...
- 09:49:11 [matt]
- wmaslowski: You could limit it to an arbitrary number, but if you pick wrong.
- 09:49:30 [matt]
- dougt: You could opt in for a site, and say "never remind me again", then when you're annoyed by it you can opt out.
- 09:50:42 [matt]
- andreip: What information would someone provide to the API to make this work?
- 09:50:52 [matt]
- steveblock: I imagine it'd be an API call per registration.
- 09:51:01 [matt]
- andreip: So stores wouldn't use it.
- 09:51:54 [matt]
- matt: Stores aren't the only use cases. Location based reminders are pretty good use case.
- 09:52:02 [matt]
- andreip: But we're arguing whether it gives a privacy advantage.
- 09:52:46 [matt]
- wmaslowski: ?? data uri … ??? warning about … would have some privacy gain, but wouldn't be a functionality gain...
- 09:53:02 [matt]
- andreip: If I try to use the current API to do coupons, then they can't because the battery drains?
- 09:53:17 [matt]
- andreip: Any real developer wanting to use this API?
- 09:53:22 [matt]
- andreip: Or is it a fictional use case?
- 09:54:03 [matt]
- dougt: I think there is a privacy gain: if you can reduce the set of lat/lng registered, then you have a gain, but if you can register 10000...
- 09:54:55 [matt]
- dougt: You could build this feature based on the current geolocation API.
- 09:55:11 [matt]
- diana: User might feel comfortable with sharing "let them know when I'm near", but not "know where I am all the time"
- 09:55:40 [matt]
- steveblock: You could imagine a UA that prompts when the proximity is hit.
- 09:55:48 [matt]
- dougt: Are there apps that do this right now? Are they popular apps?
- 09:56:34 [matt]
- dougt: Ignoring privacy you can do this today.
- 09:56:39 [matt]
- matt: And ignoring battery life
- 09:56:42 [matt]
- dougt: Users don't care.
- 09:57:08 [matt]
- lbolstad: Should we be proactive and thinking about this now?
- 09:57:52 [matt]
- steveblock: In previous cases we've had someone create the api and use it and then standardize.
- 09:58:26 [matt]
- andreip: I think we need for it to get more traction.
- 09:58:37 [dougt]
- not sure that is capturing the thought.
- 09:59:36 [matt]
- lbolstad: Should we drop it?
- 10:00:04 [matt]
- steveblock: I think there's an action item to end the thread until there is a concrete requirement.
- 10:00:32 [matt]
- dougt: The cool thing in proximity alarms is making it happen when the page loads.
- 10:00:35 [matt]
- steveblock: Or in the background.
- 10:00:35 [lbolstad]
- ACTION: andreip to reply to the proximity thread saying we're dropping it for now and will revisit it later if there's demand
- 10:00:36 [trackbot]
- Created ACTION-84 - Reply to the proximity thread saying we're dropping it for now and will revisit it later if there's demand [on Andrei Popescu - due 2011-09-14].
- 10:00:55 [matt]
- dougt: We implemented …?? … and it's very similar.
- 10:04:43 [matt]
- [[exploring Web Notifications]]
- 10:04:51 [matt]
- dougt: When a proximity alarm happens, you could have a notification show.
- 10:04:57 [matt]
- steveblock: This isn't about background events though.
- 10:13:12 [lbolstad]
- Open issues: http://www.w3.org/2008/geolocation/track/issues/open
- 10:13:59 [matt]
- ISSUE-43?
- 10:13:59 [trackbot]
- ISSUE-43 -- Proximity interface -- open
- 10:13:59 [trackbot]
- http://www.w3.org/2008/geolocation/track/issues/43
- 10:20:02 [dougt]
- we are going through the open issues and resolving some.
- 10:22:12 [matt]
- ISSUE-81?
- 10:22:12 [trackbot]
- ISSUE-81 -- Civic address format transformations -- open
- 10:22:12 [trackbot]
- http://www.w3.org/2008/geolocation/track/issues/81
- 10:22:56 [matt]
- ACTION-72?
- 10:22:56 [trackbot]
- ACTION-72 -- Andrei Popescu to to add the new requirements talked about at the f2f to the requirement section -- due 2010-11-11 -- OPEN
- 10:22:56 [trackbot]
- http://www.w3.org/2008/geolocation/track/actions/72
- 10:27:01 [matt]
- ISSUE-98?
- 10:27:02 [trackbot]
- ISSUE-98 -- Update v2 to include all recent changes in v1 -- open
- 10:27:02 [trackbot]
- http://www.w3.org/2008/geolocation/track/issues/98
- 10:29:08 [matt]
- -> http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=fpwdlc-wd-tr FPWD and LC at the same time.
- 10:30:50 [matt]
- lbolstad: What is the minimum period for the LC?
- 10:31:05 [matt]
- matt: I'll have to find out. It's I believe the greater of the two periods, whichever is longer the LC or the FPWD
- 10:31:18 [matt]
- lbolstad: We need a charter extension Matt?
- 10:31:20 [matt]
- matt: Yes.
- 10:32:43 [matt]
- lbolstad: If we can do a combined LC and FPWD, then the most optimistic would be for us to finish LC after the end of December. Get to CR, then a few months, then PR
- 10:33:03 [matt]
- matt: Actually, you can do a 0 day CR, which is basically going straight from LC to PR. You have to have your implementation report ready, etc though.
- 10:33:14 [matt]
- dougt: So we probably need a charter extension.
- 10:33:38 [dougt]
- because there is no way to get these specs to rc before dec.
- 10:36:26 [matt]
- issue-88?
- 10:36:26 [trackbot]
- ISSUE-88 -- Should we change the orientation axes ? -- open
- 10:36:26 [trackbot]
- http://www.w3.org/2008/geolocation/track/issues/88
- 10:37:48 [matt]
- Topic: DeviceOrientation Events
- 10:48:05 [matt]
- andreip: We can close the issue as we resolved it on the mailing list.
- 10:49:20 [matt]
- ISSUE-93?
- 10:49:20 [trackbot]
- ISSUE-93 -- Add window.ondevicemotion, window.ondeviceorientation ? -- open
- 10:49:20 [trackbot]
- http://www.w3.org/2008/geolocation/track/issues/93
- 10:49:36 [steveblock]
- ACTION: steveblock Add non-normative text regarding origin for Geolocation V2 and DeviceOrientation
- 10:49:37 [trackbot]
- Created ACTION-85 - Add non-normative text regarding origin for Geolocation V2 and DeviceOrientation [on Stephen Block - due 2011-09-14].
- 10:52:36 [steveblock]
- ACTION: steveblock Add window.ondevicemotion and window.ondeviceorientation
- 10:52:36 [trackbot]
- Created ACTION-86 - Add window.ondevicemotion and window.ondeviceorientation [on Stephen Block - due 2011-09-14].
- 11:53:44 [steveblock]
- steveblock has joined #geolocation
- 11:53:48 [dougt]
- hi matt
- 11:53:51 [dougt]
- we're back
- 11:54:44 [matt]
- OK, I'll dial back in.
- 11:55:13 [andreip]
- andreip has joined #geolocation
- 11:55:15 [wmaslowski]
- wmaslowski has joined #geolocation
- 11:56:39 [lbolstad]
- lbolstad has joined #geolocation
- 11:58:24 [matt]
- rrsagent, draft minutes
- 11:58:24 [RRSAgent]
- I have made the request to generate http://www.w3.org/2011/09/07-geolocation-minutes.html matt
- 11:58:47 [lbolstad]
- scribe lbolstad
- 11:58:48 [dougt]
- ACTION: matt hand out geolocation stickers to dougt.
- 11:58:51 [trackbot]
- Created ACTION-87 - Hand out geolocation stickers to dougt. [on Matt Womer - due 2011-09-14].
- 11:59:07 [lbolstad]
- scribe: lbolstad
- 12:00:12 [dougt]
- change the due date? ;p
- 12:00:51 [matt]
- ACTION-87 due 2011-11-03
- 12:00:51 [trackbot]
- ACTION-87 Hand out geolocation stickers to dougt. due date now 2011-11-03
- 12:00:59 [dougt]
- heh
- 12:01:06 [matt]
- trackbot, good boy
- 12:01:06 [trackbot]
- Sorry, matt, I don't understand 'trackbot, good boy'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
- 12:03:27 [lbolstad]
- issue-95?
- 12:03:27 [trackbot]
- ISSUE-95 -- Should we separate out compass heading? -- open
- 12:03:27 [trackbot]
- http://www.w3.org/2008/geolocation/track/issues/95
- 12:15:51 [lbolstad]
- discussing the issues raised around event listeners and side effects
- 12:15:52 [lbolstad]
- http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0023.html
- 12:18:36 [lbolstad]
- should we or should we not give the (immediate) initial state when an event listener is added ?
- 12:20:11 [lbolstad]
- do we care about the initial value?
- 12:20:40 [lbolstad]
- in practice the slightest noise would generate an event anyway
- 12:24:23 [lbolstad]
- but not if this is filtered out
- 12:33:26 [lbolstad]
- the "controversial" part of the spec is this: when a new listener registers for the event, implementations should fire the event as soon as sufficiently fresh data is available.
- 12:34:32 [lbolstad]
- the very first event listener will cause the underlying sensor APIs to be triggered
- 12:35:22 [lbolstad]
- and will receive an event, which is fine because fresh data became available
- 12:36:01 [lbolstad]
- the question is what a second event listener, whether in the same document or not, should receive cached sensor data as soon as it is added
- 12:41:39 [lbolstad]
- we'll bring this up with the www-dom mailing list
- 12:41:49 [lbolstad]
- s/with/on
- 12:41:53 [lbolstad]
- s/with/on/
- 12:41:58 [steveblock]
- ACTION: steveblock Send email to www-dom regarding initial event
- 12:41:58 [trackbot]
- Created ACTION-88 - Send email to www-dom regarding initial event [on Stephen Block - due 2011-09-14].
- 12:59:19 [matt]
- issue-100?
- 12:59:19 [trackbot]
- ISSUE-100 -- Figure out how to send initial event to new listeners -- open
- 12:59:19 [trackbot]
- http://www.w3.org/2008/geolocation/track/issues/100
- 13:09:19 [lbolstad]
- back to issue-95...
- 13:10:09 [lbolstad]
- does it make sense to separate out compass heading and accuracy as separate properties, as Apple have done ?
- 13:27:57 [lbolstad]
- after a lengthy discussion we struggle to find good reasons for adding sensor-specific properties to the interface
- 13:32:26 [lbolstad]
- ACTION: andreip to follow up with Dean Jackson to get more details on webapps breaking as a result of combining compass and gyro data
- 13:32:27 [trackbot]
- Created ACTION-89 - Follow up with Dean Jackson to get more details on webapps breaking as a result of combining compass and gyro data [on Andrei Popescu - due 2011-09-14].
- 13:34:02 [lbolstad]
- Topic: Keylogging based on accelerometer data
- 13:37:02 [lbolstad]
- http://www.cs.ucdavis.edu/~hchen/paper/hotsec11.pdf
- 13:39:22 [lbolstad]
- Should this be addressed in the spec or left to the UAs to mitigate ?
- 13:40:17 [lbolstad]
- Doug: The obvious protection is to block events to background or non-visible documents/apps
- 13:40:34 [lbolstad]
- Doug: Preferable not to even mention this in the spec
- 13:45:40 [lbolstad]
- Resolution: We won't address this in the spec, but we expect implementations to provide adequate protection by for instance not firing events to non-visible/background web pages
- 14:18:12 [lbolstad]
- Topic: Cache polling
- 14:18:13 [lbolstad]
- http://lists.w3.org/Archives/Public/public-geolocation/2011Aug/0001.html
- 14:19:29 [lbolstad]
- A site can specifically request a cached location by setting maximumAge to Infinity
- 14:19:56 [lbolstad]
- This location could be one that the user is not expecting to share with the current site
- 14:21:55 [lbolstad]
- We agree that this could be considered data leakage, on the other hand the threshold for sharing location in the first place is already high
- 14:22:40 [lbolstad]
- Also, no site can rely on getting a cached position of a certain age
- 14:23:40 [lbolstad]
- The wg consensus is that no API change is required to address this, but that UAs should perhaps consider protecting against sites receiving old position data shared with other sites
- 14:24:16 [lbolstad]
- Topic: Two security issues
- 14:24:21 [lbolstad]
- http://lists.w3.org/Archives/Public/public-geolocation/2011Aug/0006.html
- 14:25:48 [lbolstad]
- First one: The spec does not explicitly specify the lifetime of a watchPosition process
- 14:26:38 [lbolstad]
- We should ask hixie for a clarification here
- 14:28:28 [lbolstad]
- ACTION: andreip to clarify with hixie what the Geolocation spec should say about stopping watchPosition processes on document unload
- 14:28:28 [trackbot]
- Created ACTION-90 - Clarify with hixie what the Geolocation spec should say about stopping watchPosition processes on document unload [on Andrei Popescu - due 2011-09-14].
- 14:29:29 [lbolstad]
- Second one: dougt will reply on the mailing list
- 14:35:41 [DKA]
- DKA has joined #geolocation
- 14:37:49 [lbolstad]
- \Matt no
- 15:16:05 [lbolstad]
- Topic: Restrict location accuracy requested by developers
- 15:17:06 [lbolstad]
- Ernesto: It would probably be a good feature for developers to be able to restrict the accuracy of location requests
- 15:17:16 [lbolstad]
- e.g. request only city- or country level location
- 15:17:29 [lbolstad]
- We've obviously had this discussion before
- 15:19:09 [matt]
- [[We've had the discussion before, but always said: "not doing it with lat/lng" and "address we'll handle in v2", so I don't feel like we've really resolved it]]
- 15:19:22 [steveblock]
- steveblock has left #geolocation
- 15:19:28 [lbolstad]
- ACTION: dchen to collect feedback from developers about location accuracy and present at the next f2f
- 15:19:28 [trackbot]
- Sorry, couldn't find user - dchen
- 15:20:20 [matt]
- ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f
- 15:20:20 [trackbot]
- Sorry, couldn't find user - dcheng
- 15:21:11 [lbolstad]
- rssagent, draft minutes
- 15:21:38 [matt]
- ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f
- 15:21:38 [trackbot]
- Sorry, couldn't find user - dcheng
- 15:21:58 [matt]
- trackbot, status
- 15:22:02 [matt]
- trackbot, reload
- 15:22:19 [matt]
- rrsagent, draft minutes
- 15:22:19 [RRSAgent]
- I have made the request to generate http://www.w3.org/2011/09/07-geolocation-minutes.html matt
- 15:22:31 [matt]
- trackbot, status
- 15:22:36 [matt]
- ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f
- 15:22:36 [trackbot]
- Sorry, couldn't find user - dcheng
- 15:22:40 [lbolstad]
- ACTION: Diana to collect feedback from developers about location accuracy and present at the next f2f
- 15:22:42 [trackbot]
- Created ACTION-91 - to collect feedback from developers about location accuracy and present at the next f2f [on Diana Cheng - due 2011-09-14].
- 15:22:54 [lbolstad]
- rrsagent, draft minutes
- 15:22:54 [RRSAgent]
- I have made the request to generate http://www.w3.org/2011/09/07-geolocation-minutes.html lbolstad