RE: New attribute suggestion

 

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