- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 6 Jun 2008 11:15:42 -0700
- To: Doug Schepers <schepers@w3.org>
- Cc: public-geolocation@w3.org
On Jun 6, 2008, at 10:55 AM, Doug Schepers wrote: > Hi, Folks- > > (- public-webapi, just to reduce cross-posting) > > > Maciej Stachowiak wrote (on 6/6/08 12:58 PM): >> On Jun 6, 2008, at 7:55 AM, Mark Baker wrote: >>> On Thu, Jun 5, 2008 at 4:20 PM, Andrei Popescu >>> <andreip@google.com> wrote: >>>> >>>> I am interested in working on a specification of a DOM API that >>>> allows >>>> Web pages to access the user's geolocation information (e.g. >>>> latitude >>>> and longitude). >>> >>> I'm very glad to see somebody mention using the DOM API for this >>> kind >>> of information, right off the bat. I'm a big believer in reuse, and >>> feel that this API is an obvious candidate for reusing the DOM, i.e. >>> providing a "Location" Javascript object that's also a DOM Document. >> I don't understand why you would want the "Location" object to be a >> DOM Document. (It needs a better name, by the way, so it doesn't >> conflict with the Location object that is window.location.) And I >> don't think that is what Andrei had in mind, as I understand it, he >> just wants an API that aligns well with the DOM, not necessarily >> one that makes non-markup information appear to be part of a >> Document. > > I think I read the idea of hanging it off the Navigator object > instead of the Document or Window object, which puzzled me... a > request for access comes directly from a particular site, so > granting it should apply only to the requesting tab/window. The navigator object has traditionally been the place to hang information and APIs that are not specific to a particular frame or document (like UA version info, available plugins, online/offline status, etc). But I could see doing it either way. > > > >> I think presenting geolocation info as a Document would have the >> disadvantages of more memory use and less obvious access for authors. >> What are the advantages? > > I'm not sure I'd count it as an advantage, but there is the way KDDI > [1], DoCoMo [2], and (as information) Microformats [3] deals with > this in markup. I'm not suggesting we align around that, more > mentioning it for context. Interesting... > <off-topic> > I'm sure it's out of scope for the Geolocation API, but it might be > interesting to discuss how location could be codified in markup such > that if you found a resource that had a specific location (a web > page for a pizza place), a user could find the relation between > their current location and that place. I know, more of a service, > but I thought I'd toss it out there. > </off-topic> > > [1] http://sideshowbarker.net/gps/ > [2] http://www.nttdocomo.co.jp/english/service/imode/make/content/gps/ These both seem to be a way to send location info to a server along with an HTTP request (via an HTML extension), not a client-side API. There doesn't seem to be a document representation of the location info itself, it is just a string sent as an extra request parameter, at least in the DoCoMo case. > [3] http://microformats.org/wiki/geo Interesting, though I don't think this includes all the info we'd want in a geolocation response. Regards, Maciej
Received on Friday, 6 June 2008 18:16:23 UTC