W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2009

Re: updated editor's draft of the Geolocation API specification

From: Andrei Popescu <andreip@google.com>
Date: Tue, 9 Jun 2009 13:13:15 +0100
Message-ID: <708552fb0906090513g60d067c5ob9dd756f012f3c58@mail.gmail.com>
To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Cc: Lars Erik Bolstad <lbolstad@opera.com>, public-geolocation <public-geolocation@w3.org>
On Tue, Jun 9, 2009 at 1:02 PM, Marcin
Hanclik<Marcin.Hanclik@access-company.com> wrote:
> Hi Andrei,
>>>both hasFeature()
>>>and "geolocation.version" would fit the bill.
> Do you intend to have both of the above?

No, I guess one would be sufficient.

> In general I would opt for a single access point to the version information.

Sure, me too.

> I assume, however, the different use cases:
> - hasFeature() is for the JS code to check for a specific version of the API
> - geolocation.version is to query the implementation version.

I'm not sure I see the difference between the two. hasFeature is on
the DOMImplementation iface, so it asks the implementation if it
supports a certain version of a certain feature. This is exactly the
same as querying the navigator object to see if geolocation is
supported and then looking at geolocation.version.

> So I have the following comments:
> 1. what gets returned by geolocation.version if there are 2 implementations within the run time, e.g. 1.0 and 2.0?

Hmm, how can there be two implementations behind the same geolocation object?

> 2. If there will be multiple implementations present within a single runtime (why not...?), how the JS code could choose the one it was developed for (e.g. JS code is developed for 1.0 in 2009 and the author wants to ensure that her/his code is future proof)?

I don't think we explicitly support a mechanism for an app to
dynamically change the implementation at runtime. If some product
wants to support that, I guess it could define its specific mechanism,
outside of this specification. For instance, you could imagine several
NPAPI plugins that implement this spec. The JS code could iterate over
them and test for their version attribute.

> 3. The current spec shall state that it is in 1.0 version. Maybe the title would be a good place for that? Like " Geolocation API Specification 1.0". I am not sure how V2 is to look like, based on the current spec or completely new etc.

Ah, we have an editor draft for V2:


> Taking the above point 2 into account, I assume geolocation.version may be not needed, since the JS Code is usually developed against a concrete API version, so hasFeature() could do all what is needed.

Sure, I think hasFeature() would work. Let's see what the rest of the
groups says.

All the best,
Received on Tuesday, 9 June 2009 12:13:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:56 UTC