- From: Robin Berjon <robin@berjon.com>
- Date: Thu, 10 Mar 2011 14:04:07 +0100
- To: Rich Tibbett <rich.tibbett@gmail.com>
- Cc: Dominique Hazael-Massieux <dom@w3.org>, Rich Tibbett <richt@opera.com>, public-device-apis@w3.org
On Mar 10, 2011, at 11:57 , Rich Tibbett wrote: > We've talked about standards success factors previously. For me producing specifications is not the end-game; ubiquitous support across all UAs is. If an API is not ubiquitously accessible across all UAs then web developers can't reliably code against such APIs. I think that's a given. > We should give ourselves the highest possibility for producing successful specifications backed by ubiquitous implementations by working on specifications that have a large level of interest. The problem is that your approach isn't much less based on second-guessing than any other. In the absence of participation from relevant parties, the best strategy is to try to put together the best technical solution based on known use cases and expected best practice, and see how that can be promoted in order to foster participation. One big advantage of having a super simple API like the one that Dom proposed is that it's pretty easy to implement in an extension in order to show that it's useful and safe — or to see that it fails, but at least on merits rather than politics and second-guessing. > Going back to the non-API proposal, if we were to utilize the uri schemes then it's not an absolute requirement for all UAs to implement such a scheme. UAs could theoretically implement uri schemes without requiring any reliance on other vendors to reciprocally implement anything. IMO, producing uri schemes carries a lower risk factor than APIs in this case. I don't think that this argument makes sense. What developers want is interoperability. Whether it's an API, a URI scheme, or a pole-dancing rabbit it's either there or it's not. -- Robin Berjon - http://berjon.com/
Received on Thursday, 10 March 2011 13:04:41 UTC