Re: Indoor API in new charter?

For indoor location, I think if the goal is to provide things like floor
level or even venue information, then the API changes quite a lot. I'll see
if I can find out something about indoor location on Android.

My other concern related to maturity / readiness regards the proposed
geofencing feature. I think it would be most useful if a geofencing event
could wake up the browser app even if it is not currently in the
foreground, and load the web app if necessary. Without that, the feature
won't be nearly as useful. The worry I have is that this suggests a
dependency on App Lifecycle and thus ServiceWorker. Both those specs are
immature.

Regards,

Michael


On Thu, Nov 21, 2013 at 9:54 AM, Dominique Hazael-Massieux <dom@w3.org>wrote:

> Hi,
>
> The proposed new charter for the group currently has a deliverable for
> indoor location:
>
> http://lists.w3.org/Archives/Public/public-geolocation/2013Nov/att-0003/Proposed_Geolocation_Working_Group_Charter.htm#deliverables
>
> During discussions last week in TPAC, there was unclarity on:
> * whether indoor location needed anything special in the API (i.e. only
> required browsers to use whatever location technology is available
> indoors)
>
> * if it did, whether there was sufficient experience with these
> specificities to proceed with standardization; for instance, there
> doesn't seem be to an official iOS or Android indoor location API
>
> I would be interested in getting views on these two considerations.
>
> If any of the two is confirmed, I think including indoor location in the
> new charter as a Rec-track deliverable is probably premature; in which
> case, I would suggest we keep the topic on, but as "use case and
> requirements" deliverable, rather than for an API.
>
> Thanks,
>
> Dom
>
>
>
>