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

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

From: Robin Berjon <robin@robineko.com>
Date: Thu, 27 Aug 2009 14:29:41 +0200
Cc: public-device-apis@w3.org
Message-Id: <8149D51F-D344-4702-BA78-9A874DEF12BA@robineko.com>
To: Marcos Caceres <marcosc@opera.com>
Hi all,

On Aug 27, 2009, at 11:21 , Marcos Caceres wrote:
> I think we should just take a vote (or something) and reach a formal  
> resolution and be done.

I'd rather not put it to a vote just yet, but since indeed at this  
point we seem to have the same people with the same arguments, a straw  
poll should give us an idea of whether it's worth the effort of going  
through the same motions again.

> As a process thing. It would be nice to have a place where the  
> group's resolutions are publicly available. Is there some way to  
> suck resolutions out of Trackbot?

I don't think so; certainly not resolutions that don't have an issue.  
In general though I think that pointing at discussion in the issue and  
at the mailing list is enough?


On Aug 27, 2009, at 12:38 , Marcin Hanclik wrote:
> The only issue is what we vote for and against?

The question is whether to have explicit versioning mechanisms in v1,  
such as hasFeature(), a version attribute, or a version parameter to  
constructors.

> If we vote against versioning, what is then the practical alternative?

The one that pragmatically reflects real-world experience with the  
fact that API-versioning approaches have failed on the web and do not  
correspond to existing documented best practices.

> Some statistics:
>
> a)
> XMLHttpRequest [1] defines 1 interface with 5 methods and 6  
> attributes.
> Additionally [1] states what is left for future [2].
>
> b)
> BONDI 1.01 [3] defines a bit more as summarized at [4]:
> interfaces: 68,
> attributes: 116,
> constants: 82,
> methods: 177,
> typedefs: 24.
>
> The above provides very rough information about the extent of what  
> we are heading for.
> When starting the work in DAP I think we should prepare ourselves to  
> cope with that amount of Web IDL, accompanying documentation, state  
> machines etc.

I don't think that these statistics inform the debate. The full DOM  
set that's available in browsers (Core 3, Events 3, HTML, SVG, Element  
Traversal, CSS, Views, Range, XML to name those that come to mind) is  
*way* larger than BONDI (the IDL for the SVG DOM alone is 1300 lines  
without comments  three times BONDI), it has a versioning mechanism,  
and that has been shown not to work in browsers (it works for Java,  
but Java-like ecosystems are irrelevant to this discussion).

> Versioning may help and it is a kind of security policy, just in  
> case we would need to break backwards compatibility due to some  
> technical arguments coming late.

If a technical arguments comes after Last Call, it's too late. That's  
why it's called Last Call :)

> The issue is whether the outcome of DAP, i.e. the documents/ 
> standards will be usable for a potential user/developer and how they  
> are going to evolve process-wise.

Of course, that's why we'll handle evolution on our side, and not  
expose it to developers who don't care about it.

--
Robin Berjon
   robineko  setting new standards
   http://robineko.com/
Received on Thursday, 27 August 2009 12:30:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:13:59 GMT