What if we have a formal definition for the API that is independent of any implementation? Cheers Keean On Apr 1, 2011 5:57 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > On Fri, Apr 1, 2011 at 9:39 AM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote: >> So if the only objection to WebSQL is "there's no way we're going to >> get a formal spec or two interoperable implementations", I'd really >> encourage objectors to step back and ask themselves why they *want* a >> formal spec and two interoperable implementations. Those requirements >> are not axiomatic, they're means to obtain practical ends like >> allowing competitions and avoiding user lock-in. How many of those >> ends are really contrary to using SQLite as a de facto standard, and >> do the remaining ones really outweigh the practical advantages? > > The standard reason for not depending on a reference implementation > still apply - if you depend on a reference implementation, then you > implicitly depend on its bugs as well. > > This isn't a huge problem for individual projects, which can work > around the bugs on their own, and more importantly, fix their code if > they update to a new version without those bugs. As you know, the web > doesn't work like that. If we all exposed the same implementation of > sqlite, the body of code on the web would grow to meet and depend on > all the bugs in that implementation. Any bugfixes would have an > associated compatibility cost, which is much larger than normal > because all browsers agreed on the bug. > > We try to require two independent implementations for the same reason > you're not allowed to have children with your siblings - multiple > implementations with the same bugs are much worse than multiple > implementations with different sets of bugs, even if the total > quantity of bugs is higher in the latter situation. > > ~TJ > > (I didn't realize I was heading toward an incest analogy when I > started this reply. I stand by my decision.) >
Received on Monday, 4 April 2011 16:57:27 UTC