- From: Moon-Sang Lee <sang0627.lee@samsung.com>
- Date: Wed, 03 Dec 2008 12:06:14 +0900
- To: 'Doug Turner' <doug.turner@gmail.com>
- Cc: public-geolocation@w3.org
- Message-id: <00be01c954f4$1a61a4d0$4f24ee70$%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. 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. 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. I think attributes which seem primitive need to be included in standardizing. Thanks.. Sam Lee From: Doug Turner [mailto:doug.turner@gmail.com] Sent: Wednesday, December 03, 2008 12:53 AM To: Moon-Sang Lee Cc: public-geolocation@w3.org Subject: Re: New attribute suggestion Hi Moon-Sang Lee, The use cases are interesting and most useful. However, i am not sure why you couldn't implement this with the current api? For example: navigator.geolocation.watchPosition(success_callback, null, null); function success_callback(position) { var request = new XMLHttpRequest(); request.open("POST", "http://dougturner:xxxxx@twitter.com/account/update_location.xml?location=" + position.longitude + "," + position.latitude, false); request.send(null); } if the script has access to the file system, then you can write it there. if there isn't access to the network, you can just add these locations to an array and push when there is reception/net-access. Doug On Dec 1, 2008, at 10:52 PM, Moon-Sang Lee wrote: Dear Geolocation WG members, Hello everybody. I’ve heard about this WG a few days ago, and briefly read the editor’s draft. And I’d like to suggest to discuss about position logging. In accordance with position acquirement, can we log the acquired current position into a repository? A repository can be a local file in a portable device or it can be a remote server. If we extend the Gelocation API to log one’s position, it can support many useful use cases and help application developers work easy. Here is our proposal for extending the current Geolocation API draft, if it’s still open. [ Location Logging ] We think Geolocation API would be much better when it adopts logging facility. (i.e. It’s different from caching one’s position.) The use cases for this feature are as below. - Preventing the emergency situation Let’s assume that a person is climbing a mountain on a weekend. A portable device which he carries in his bag or pocket traces the location of himself by using the local GPS or broadband network. If he enters into a dangerous area where he may lose his way, the device warns him that it’s not safe to go further in that direction. In addition, his position is periodically recorded to the local device storage or delivered to a remote rescue server if he had configured the automatic logging. In this case, the device plays as a personal black-box, which can be used to rescue him in an emergency if his position is periodically delivered to a remote rescue server. Furthermore, he can upload his trace to his own blog while recommending his pleasant journey to his friends. - Asking emergency aid Let’s assume that a person is entering an area where crime is rife in a dark rainy night. The portable device notifies him of such dangerous situation. But, he decides to go on since he is in a hurry for appointment. He turns on the soft-911 mode of his device to verify the location of the nearest police man and to let the policeman know his location for provision against emergencies. In case of emergency, he can easily manage the situation by sending the request for emergency aid to the nearest policeman who has been tracking his position. The track under the soft-911 mode is temporarily stored to a remote 911 server until he turns off the mode. For above use cases, it’s necessary to store one’s position for a while, and we need additional functionalities besides those in editor’s draft. The required features are as below. - Whether to log : boolean flag (True/False) - Where to log : log repository (URL) - When to log : logging frequency (TimeInterval) Obviously, these features can be handled by application, but it’s too complicated to control logging without these features. We think that our proposal would raise new kind of web service and proliferate storage backend of cloud-computing. interface PositionOptions { attribute boolean enableLog; /* added */ attribute string loggingURL; /* added */ attribute long interval; /* added */ attribute boolean enableHighAccuracy; attribute long timeout; attribute long maximumAge; }; Thanks for reading. With regards, Moon-Sang Lee & Min-Soo Koo
Received on Wednesday, 3 December 2008 03:07:01 UTC