W3C home > Mailing lists > Public > public-geolocation@w3.org > December 2008

RE: New attribute suggestion

From: Moon-Sang Lee <sang0627.lee@samsung.com>
Date: Thu, 04 Dec 2008 10:30:35 +0900
To: 'Andrei Popescu' <andreip@google.com>
Cc: 'Doug Turner' <doug.turner@gmail.com>, public-geolocation@w3.org
Message-id: <00ec01c955af$e8129720$b837c560$%lee@samsung.com>

Hi, and thanks for your interest. 

> -----Original Message-----
> From: Andrei Popescu [mailto:andreip@google.com]
> Sent: Thursday, December 04, 2008 12:10 AM
> To: Moon-Sang Lee
> Cc: Doug Turner; public-geolocation@w3.org
> Subject: Re: New attribute suggestion
> Hi,
> 2008/12/3 Moon-Sang Lee <sang0627.lee@samsung.com>:
> >
> >
> > Hi Doug,
> >
> >
> >
> > Thanks for your comment, and I want to mention several things regarding your
> > comment.
> >
> > First of all, as you've shown with a AJAX code, logging feature can be
> > implemented in application(script) level. (i.e. I also mentioned it in the
> > last paragraph of my original email.) I think this is not about
> > possible-impossible problem but about the scope of Geolocation API. If we
> > provide the logging feature with Geolocation API, it helps programmers make
> > their web applications easy.
> >
> The use cases you presented are certainly valid but I don't think that
> adding the functionality you suggest is in the scope of this API. To
> me, this is clearly application logic that can be implemented using
> several existing Web APIs. For offline storing of location waypoints,
> one can use HTML5's Database API (or even cookies) and periodically do
> batch uploads to a server using XHR (as Doug also suggested).

Ok, if we agree with the logging use cases, let's focus on what's 'primitive' in
Geolocation API. The Geolocation API defines a high-level interface to location
information according to the editor's draft. Does the high-level interface deal
with acquiring process only? If so, the logging functionality should be
implemented using existing Web APIs as you mentioned. But, if not, what about
this? I think it looks simple and useful.

// options include to depict logging feature
navigator.geolocation.getCurrentPosition(successCallback, errorCallback,

> > In addition, we can reduce the logging latency and network traffic if we use
> > the extended API. Let's assume  that a network server tells me where I am.
> > (i.e. My host device does not have a GPS module or uses a network server for
> > position accuracy.) When the logging feature is implemented in application
> > level, there should be two network requests, one for acquiring the current
> > position and the other for logging the current position. However, we can
> > send only one request for both of acquiring and logging the current position
> > if the Geolocation API provides remote logging.
> >
> But that's only the case if the server that gives you location is the
> same as the server that does the logging. However, this will probably
> be pretty rare in practice. And anyway, if the logging and location
> server are one and the same, then you can do the logging
> automatically, without the need for any extra arguments in the
> Geolocation API, right?

Not really. Two servers do not need to be the same for one network request.
Extra arguments including loggingURL specify the source of location information
to relay one's current position to a remote logging server. In addition, every
position request might be logged without extra arguments, and that's not what we

> > There are various web browsers, particularly, in mobile devices. And, each
> > browser has its own plug-in structure. If we want to log our tracks of
> > position into a host storage, we should use browser plug-ins and many
> > different plug-ins should be distributed in accordance with the browser we
> > use. In a worst case, a fine web page for a browser 'I' would not work on a
> > browser 'F' since the 'F' supports only partial of such plug-ins.
> >
> Right, but I am not sure I understand how adding some extra attributes
> to this API would affect this situation.
> > I think attributes which seem primitive need to be included in
> > standardizing.
> >
> Agreed. However, in this case these attributes are not 'primitive'.
> The functionality they would add can already be implemented using
> other standard Web APIs.

Yes, logging one's position into a permanent storage can be implemented using
browser-specific plug-in,  HTML5's DB API, javascript using XMLHttpRequest
object, etc. Does it mean that we don't need a simple fancy API for storing
positions? If personal trajectory is considered important, we may think logging
feature as primitive in my opinion.

With regards,

> Many thanks,
> Andrei
Received on Thursday, 4 December 2008 01:31:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:53 UTC