Re: skeleton Geolocation API

On 6/24/08, Nick Brachet <nbrachet@skyhookwireless.com> wrote:
>  I actually don't [have a use-case in mind for supporting multiple watch].
> It would certainly somewhat simplify the API to only have one watch.
>  Does anyone on the group have a use-case for this?

assuming you're doing mash ups by foreign <script></script> includes
and your host or their apis don't provide a way to share locations,
they might simple call the watch method....

it'd be bad if adding a second consumer broke the first one.

otoh, if it forced everyone to design their system so that public apis
accepted some other callback and then the mashup host was responsible
for coallescing this data and using it...

but in practice, i think mashup authors know very little about current
or future apis, and as such it's quite possible that two mashed up
scripts might know more about the browser than their host, leaving
them no choice but to ask the browser directly.

> > > The watchPosition() interface is too limiting as it doesn't give the
> ability
> > > to the caller to specify "intent", and therefore the implementation to
> > > adjust its behavior accordingly.
> > > For example, if the application only cares about changes in location
> greater
> > > than say 1Km,

> > That's one idea behind the enableHighAccuracy flag. As mentioned
> > already, it could do with a better name. Any ideas?

>  I think "enableHighAccuracy" is too limiting and wouldn't suffice to serve
> the use-cases I highlighted.

offhand i'm pretty sure i'm not a fan of enable high accuracy. perhaps
object parameters to watch position indicating request rate and
precision requirements.

these days, certain devices have on board gyroscopes although i'm not
quite sure how i'd use them here, i could imagine in some cases being
able to tell the application that there was a twitter without using
network or gps data. otoh, if the consumer only cares about much
larger changes, then i'd definitely not want to bother using them. a
boolean does not do a good job of expressing something which in fact
is really a scalar requirement. for a mapping application, it's
determined by map precision

Received on Tuesday, 24 June 2008 05:28:52 UTC