- From: Marcos Caceres <marcosc@opera.com>
- Date: Thu, 27 Aug 2009 13:52:41 +0200
- To: Marcin Hanclik <Marcin.Hanclik@access-company.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>
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".
Received on Thursday, 27 August 2009 11:53:25 UTC