Re: IndexedDB, what were the issues? How do we stop it from happening again?

Note: I chaired the meetings of Webapps when it decided to shelve the  
SQLite stuff and take up IndexedDB. But I am not a database expert. The  
decision was effectively made by the implementors who almost all insisted  
that WebDB was actually not worth following up (this included at least 2  
browsers who had implemented it) and that IndexedDB was a better solution,  
and more importantly the one they would be working on.

On Mon, 11 Feb 2013 12:34:04 +0100, Robin Berjon <robin@w3.org> wrote:

> On 07/02/2013 15:47 , Marcos Caceres wrote:
>> Ever since IndexedDB was released in browsers, there has been a lot
>> of criticism about the API from the developer community: mainly
>> people saying "it sucks", but not clearly articulating *why* it
>> sucks. For example:
>
> I think that there are several things that are problematic here, and it  
> might be worth teasing them apart to address them specifically.
>
> First, a lot of us are (I think increasingly) operating under the more  
> or less tacit assumption that when we try to produce high-level APIs,  
> they tend to suck for various reasons, and therefore that we should  
> produce lower-level primitives atop which people can build nicer things  
> (which we might then standardise in subsequent iterations).

Yes, I think this is a working design assumption that is very common.

> IndexedDB certainly was created with that in mind, and we're seeing the
> exact same sort of feedback in WebCrypto which has chosen the same
> approach.
>
> That doesn't lead to the conclusion that it's the wrong approach though.  
> For instance, AppCache ...
> ...But clearly people aren't happy so some aspects ought to change.
>
> In the feedback that we're getting, we should separate genuine design  
> problems from people being disappointed that they're given a low-level  
> API when they just want something simple that gets the job done.
>
> For the latter bit, I reckon it would be a good practice for groups  
> working on low-level APIs to more or less systematically produce a  
> library that operates at a higher level.

Indeed.

Telling Working Groups they should do more work before they suggest that  
everybody should live with something isn't generally popular (I can hear  
the howls of "make-work" and "too much process"). But it doesn't take a  
genius to understand that something which solves a particular problem well  
may be a poor model for a general solution. If a proposal isn't developed  
with consideration for general use, it should not be surprising when it  
turns out to be only as good as appcache. On the other hand, deriding  
solutions as "over-engineered" is not always baseless.

> This would not only help developers in that they could pick that up  
> instead of the lower-level stuff, but more importantly (at least in  
> terms of goals) it would serve to validate that the lower-level design  
> is indeed appropriate for librarification.

Or, thinking of it from the perspective of a working group chair, and then  
again from the perspective of someone who teaches developers simple stuff  
about APIs, it would help with testing. It would also provide good  
material to assist uptake, at least to the point where "end-user  
developers" (by which I mean simple folk like me) could have meaningful  
conversations with people who can make their own libraries that are good  
enough for other users (by which I mean clever folk like Yehuda), where  
the "end users" could explain their problems and the designers could  
clearly explain whether this is an issue in the API they have created, or  
just a missing bit of library code that "can probably be done in a couple  
of days"... which is of course an invitation to spend the couple of days  
and prove it.

[...]
> For the bad design bit, well, we've been missing a manual on how to  
> write good APIs for a long time.

Yes. An important aspect, as Marcos noted, is to identify what bits of  
"good" APIs are generally good, and what bits of them are good in the  
specific case of that API. And likewise, what things are not good.

> It probably wouldn't hurt if we had a group that was tasked specifically  
> with reviewing APIs. How to build that without it being bureaucratic,  
> useless, excessively political, and how to find people with the  
> bandwidth to make it work is a difficult question though. Which doesn't  
> mean that we shouldn't try — it simply means that we shouldn't jump into  
> it with unreasonably promises.

I believe that the TAG is in a position to do this, including being clear  
that it has limited bandwidth and therefore isn't going to suddenly solve  
all our problems.

Creating standards is inherently somewhat bureaucratic and almost  
inevitably somewhat political. Being "useful enough that people will  
listen to you" is a good goal that we should keep checking ourselves  
against.

As a working group chair, I would find the "dear group..." emails Marcos  
proposes to be helpful.

As an educator I would be pleased if they were clear enough that I could  
learn a bit (just enough to make mistakes), but I would be very pleased to  
have both a design cookbook, and the example of people repeatedly building  
high-level libraries on top of new low-level APIs. Which gives me some  
thoughts about how to make working groups take this on...

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Monday, 11 February 2013 17:22:42 UTC