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

Hi Andrei,

>>Hmm, how can there be two implementations behind the same geolocation object?
This would not be the same geolocation object.
The current model assumes that there is only one object.
I was thinking about more dynamic setup where the implementation is loaded at runtime by any means.

Putting the question differently:
what if some implementation would like to work with content developed against spec 1.0 and 2.0?

>>http://dev.w3.org/geo/api/spec-source-v2.html
Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: Andrei Popescu [mailto:andreip@google.com]
Sent: Tuesday, June 09, 2009 2:13 PM
To: Marcin Hanclik
Cc: Lars Erik Bolstad; public-geolocation
Subject: Re: updated editor's draft of the Geolocation API specification

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

________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Tuesday, 9 June 2009 12:35:43 UTC