W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2009

RE: ISSUE-4 (api-versioning): API Versioning [APIs - General]

From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Wed, 26 Aug 2009 22:24:29 +0200
To: "marcosc@opera.com" <marcosc@opera.com>, Anne van Kesteren <annevk@opera.com>
CC: Robin Berjon <robin@robineko.com>, "<richard.tibbett@orange-ftgroup.com>" <richard.tibbett@orange-ftgroup.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C2890C65BC9@OBEEX01.obe.access-company.com>
Hi All,

Traditionally  (discussed thoroughly in WebApps and BONDI) I am in favour of versioning.

My motivation is not based on the need to release new version of the API or syntax or whatever every month or year.
I would be happy if the standard could stay e.g. in version 1.0 forever.

The principle is: "give it a name".
We should clearly identify the parties and rules governing the ecosystem, version of the specification is such a rule for APIs and syntaxes.

My motivation is purely practical.
We have a cloud of:
a) releases of specifications,
b) incomplete or bad implementations,
c) contents.

In DOM there is hasFeature() method, e.g. explicitly used in the DOM3Events.
If we want to drop versioning then I assume we should also drop hasFeature(), since it is the same problem.
As stated below by Anne new releases of the specification may break backwards compatibility.
If it is ok, then I assume we should allow the content to advertise based what (which version of) specification it was developed.
Content developed against versionless specifications has little chance to survive and be usable if the specification changes.

It may become a requirement for the software engines to be backwards compatible for practical reasons.
As you may know, versioning - as a generic issue - is currently discussed in TAG and WHATWG, so we could first look at the arguments there, since my belief is that they are similar to ours.


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: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Marcos Caceres
Sent: Wednesday, August 26, 2009 1:09 PM
To: Anne van Kesteren
Cc: Robin Berjon; <richard.tibbett@orange-ftgroup.com>; public-device-apis@w3.org
Subject: Re: ISSUE-4 (api-versioning): API Versioning [APIs - General]


On Wed, Aug 26, 2009 at 12:46 PM, Anne van Kesteren<annevk@opera.com> wrote:
> On Tue, 25 Aug 2009 16:54:11 +0200, Robin Berjon <robin@robineko.com> wrote:
>> I'm in full agreement. I'd simply add that "approved" should normally mean
>> that it's reached Recommendation status, but can at times be extended to
>> apply to something that is really widely deployed and used (e.g. this has
>> been a guiding principle in specifying the XMLHttpRequest API, even though
>> it meant that it's not all that elegant everywhere).
> With XMLHttpRequest we are making some changes though that some could
> consider "breaking". E.g. with level 2 we're overloading send() more, and
> open() no longer throws when passed a non same-origin URL.

Agreed, so long as the the original method still works and does not
break old content.

> I think such changes should be acceptable. Making changes because
> implementations all differ from the specification and are unlikely to change
> should also be ok I think, if not encouraged.

Also agreed.

Marcos Caceres


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


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 Wednesday, 26 August 2009 20:25:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:38 UTC