- From: Erik Wilde <dret@berkeley.edu>
- Date: Thu, 13 Nov 2008 11:54:40 -0800
- To: Richard Barnes <rbarnes@bbn.com>, public-geolocation <public-geolocation@w3.org>
- CC: Andrei Popescu <andreip@google.com>
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.
Received on Thursday, 13 November 2008 19:55:36 UTC