- From: Andrei Popescu <andreip@google.com>
- Date: Tue, 9 Jun 2009 13:13:15 +0100
- 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: http://dev.w3.org/geo/api/spec-source-v2.html > 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, Andrei
Received on Tuesday, 9 June 2009 12:13:51 UTC