asciipr0n

Earlier this month the Mozilla Foundation announced Geode, an early implementation of a draft W3C specification for browser-based geo-location. The abstract of the draft specification states its mission to define “an API that provides scripted access to geographical location information associated with the hosting device.” A quick read of the draft W3C Geolocation API Specification got me thinking about how else such functionality could be implemented in the browser and used by web services.

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.

Read the rest of this entry »