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

Hi Andrei,

>>both hasFeature()
>>and "geolocation.version" would fit the bill.
Do you intend to have both of the above?

In general I would opt for a single access point to the version information.
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.

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?
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)?
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.

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.

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 1:19 PM
To: Marcin Hanclik
Cc: Lars Erik Bolstad; public-geolocation
Subject: Re: updated editor's draft of the Geolocation API specification

Hi,

On Tue, Jun 9, 2009 at 12:00 PM, Marcin
Hanclik<Marcin.Hanclik@access-company.com> wrote:
> Hi Andrei,
>
> Thanks for your prompt reply.
>
> This is the generic API versioning topic (a really big one :) ) that you may be aware of from the discussions on webapps ML.

I understand this may quickly become a complex topic. In our case,
however, I don't think it needs to be complex, so both hasFeature()
and "geolocation.version" would fit the bill.

> You may also be aware of the BONDI specs that handle this topic and that were contributed to W3C webapps.
>
> hasFeature() is ok for me as is also the general idea of having clear versioning.

Great.

> Some people may argue, however, whether version should be a number, but this is a minor issue that could be probably be easily agreed on.
>

Agreed.

> BONDI 1.0 (http://bondi.omtp.org/1.0/) proposes the versioning model as specified here:
> http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#versioning
> where the versioning is part of the IRI, e.g.
> "http://bondi.omtp.org/api/geolocation.position?v=1.0"
> as specified here:
> http://bondi.omtp.org/1.0/apis/apifeatures.html
> due to security requirements and requestFeature() method as defined in:
> http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf Section 4.3.2.
>

Thanks for the interesting pointers, I wasn't aware of BONDI's versioning model.

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:03:06 UTC