- From: Andrei Popescu <andreip@google.com>
- Date: Tue, 9 Jun 2009 12:18:50 +0100
- To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Cc: Lars Erik Bolstad <lbolstad@opera.com>, public-geolocation <public-geolocation@w3.org>
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
Received on Tuesday, 9 June 2009 11:19:25 UTC