The draft defines an API to be made available to any Javascript running in the browser. While the browser itself is responsible for getting the user’s current location from the operating system, it’s client-side Javascript that makes use of this location information. Provided in the draft are examples like the following:

function showMap(position) {
// Show a map centered at (position.latitude, position.longitude);
}
// One-shot position request.
navigator.geolocation.getCurrentPosition(showMap);

Such an interface allows for a high-level of interactivity on the client-side as Javascript controls and has access to all aspects of the client’s location information. However, I feel this comes at the costs of a standardized location format and portability. First, if the client wishes to gather information from a web service using the current location as a parameter, the client-side script must encode and transmit this information to a server. The format in which this information will likely vary greatly. One developer might choose to transmit this information in this manner: http://nearestfood.com/pizza?lat=1.234&long=1.234. Another might transmit this same information another way: http://iamhungry.com/pizza?latlong=1.234,1.234. There is no standard in how the client’s location is represented. Second, the client must support Javascript, which in the case of mobile device clients, is not yet a given.

One solution is to transmit client location information via a standardized request header field similar to Accept-Language. For example, we could add Client-Location to the existing set of header field definitions. The format could look like the following:

Client-Location: lat=1.234, long=1.234

By amending a new standard field definition we gain two advantages. First, there is a consistent format in how the location is represented. Second, the client does not need Javascript to transmit location information to the server. More importantly, the client no longer needs be a browser, but anything capable of making HTTP requests: from HTTP clients like wget and cURL to other web services.

Let’s see how our request header field implementation fulfills the requirements set in the W3C draft specification:

1. Find points of interest in the user’s area
   A request is made to a web service containing points-of-interest data. The server reads the user’s location from the request header and returns appropriate information.
2. Annotating content with location information
   When a POST is made to a web service, the server application reads location information from the header and annotates the POSTed resources appropriately.
3. Automatic form-filling
   When a request is made to the server, the headers are read and the address portions of the form are pre-populated with the address of the user’s current location.
4. Show the user’s position on a map
   When a request to a mapping service is made, the displayed map is automatically centered on the location given in the request header.
5. Turn-by-turn route navigation
   The client must periodically poll the navigation service, sending the user’s new location each time in the request header fields. Careful use of caching and Etags should minimize some of the negative effects of polling.
6. Alerts when points of interest are in the user’s vicinity
   Same as #5.
7. Up-to-date local information
   When a user makes a request to a news service, the server narrows down the returned content to what is relevant to the user’s locality deduced from the request header fields.
8. Location-tagged status updates in social networking applications
   Each time the user POSTS a status update to Twitter or Facebook, the server annotates the user’s new status with the location information read from the POST request header.

As you can see, it doesn’t look like we will lose any functionality with a request header field based implementation, but we will gain portability and consistency.