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: Thu, 27 Aug 2009 18:01:29 +0200
To: Marcos Caceres <marcosc@opera.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>, Anne van Kesteren <annevk@opera.com>, Robin Berjon <robin@robineko.com>, "<richard.tibbett@orange-ftgroup.com>" <richard.tibbett@orange-ftgroup.com>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C2890C65C4E@OBEEX01.obe.access-company.com>
Hi Marcos,

>>True. Use cases and requirements first.
+1

>>We should totally ignore the
>>fact that APIs have been contributed.
Please do not combine versioning with contributions. These are different things.

BTW: I do not say that any contributed API should be taken as is, but why to reinvent the wheel?

The contributed APIs seem to be based on various governing principles / design patterns and probably they could be discussed first with the hope that a set of principles could be found that would combine the best of the contributed ones and that we could agree on them.

>> and then, once we know what the
>>problems are, look at what APIs solve the problems/use cases. The we
>>avoid having "a solution looking for a problem".

The initial problem is that there is no device API in W3C, I think.
And the contributions just try to help solve this problem.

Thanks,
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: Marcos Caceres [mailto:marcosc@opera.com]
Sent: Thursday, August 27, 2009 1:53 PM
To: Marcin Hanclik
Cc: public-device-apis@w3.org; Anne van Kesteren; Robin Berjon; <richard.tibbett@orange-ftgroup.com>
Subject: Re: ISSUE-4 (api-versioning): API Versioning [APIs - General]



Marcin Hanclik wrote:
> Hi Marcos,
>
> In versioning the most important seems to be not the version identifier of the specification document, but the version identifier of the specification embedded in the content.
> It provides means for the potential implementation to identify the content for potential incompatibilities.
> Otherwise we have at least 2 options:
> 1) content sniffing by the implementation
> 2) unnecessary code in the content to guess/sniff the underlying implementation
>
>>> Levels: build ontop, don't break backwards compatibility.
>
> I am all for not breaking the backwards compatibility.
> As Anne stated earlier in the case of XHR the bc was broken and handled implicitly.
> What then if we would really have to break backwards compatibility?
> Shall we give up the whole related ecosystem?
> Wouldn't it be better to state now - at start - that breaking of the backwards compatibility is not intended, but MAY happen, and we are prepared for it?

Hold it right there, mister! I'm not getting dragged into another debate
about versioning!:)

>>> Sure. Is the above ok?
> Not really. I think about some technically detailed solution, a kind of pattern for handling this issue.
>
>>> Yikes! We got some work to do then! Hopefully, we can get those numbers
>>> down to something more reasonable.
> I am not sure whether less entities will handled the planned use cases.
> Also I do not know what number is meant as reasonable and whether minimizing that number is our ultimate target.
> I may however think of the distribution of the entities, e.g. more constants and less interfaces or so.
> This is then an API Design Pattern that we could elaborate on.

True. Use cases and requirements first. We should totally ignore the
fact that APIs have been contributed, and then, once we know what the
problems are, look at what APIs solve the problems/use cases. The we
avoid having "a solution looking for a problem".

________________________________________

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 Thursday, 27 August 2009 16:02:38 UTC

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