Re: Forward/backward compatibility

On Nov 13, 2008, at 11:54 AM, Erik Wilde wrote:

>
> Richard Barnes wrote:
>> So I would be much more comfortable if a geodetic location were  
>> optional (at least in v2), since there are deployments were it  
>> would be detrimental (inaccurate and unnecessarily complex) to add  
>> geodetic location.  I'm not sure how do go from a geodetic-only API  
>> to one where geodetic is optional in a backwards-compatible fashion.
>
> my proposal would be to solve this by creating a more comprehensive  
> API and model of location, which optionally may point to a lat/long  
> API, if that is a kind of location that is required and available in  
> a scenario. assuming that the lat/long API itself might evolve into  
> a more general location API would require it to add so many  
> constraints to it (such as almost everything in version 1 would have  
> to be treated as optional), that in my opinion it would be unlikely  
> that it actually would be implemented correctly. which would mean  
> that you would end up with v1 APIs not behaving correctly and thus  
> breaking v2 code.
>
> going for the low-hanging fruit is a good strategy, but i think it  
> is important to realize that there are many more available, and we  
> should be careful to not negatively impact the ability to get those  
> fruit a little later...
>
> cheers,
>
> dret.
>



I am thinking along the lines of adding additional options to the  
PositionOptions to request addtional geolocation information from any  
backend provider.  For example, if you want to get a civic address,  
you would do something like (hand waving):

var options = {
   additional_options = "address";
};

function a(pos) {
  var address  = pos.options("address");
  alert(address.zipcode);
}

navigator.geolocation.watchPosition(a, b, options);

I know the names of the attributes are not right, but I hope you get  
the idea. it would allow the extensiblity required for v2 and address  
the concerns about "dropping geopriv info".

Thoughts?