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

On Thursday, 7 February 2013 at 15:43, John Kemp wrote:

> > What do you think?
>  
>  
> I think a TAG-like thing to do about that would be to publish a document  
> describing "W3C Best Practices for the Design of Javascript APIs", and  
> to take guidance from those places where it is considered good  
> Javascript is written (how about a collaboration with ECMA?)

I don't know if the TAG or ECMAScript knows best™. The problem is that the guidance could be misapplied (I'm thinking of all the APIs that tried to copy Geolocation, and failed spectacularly to understand what was actually good/bad about that API). Also, the design of an API should really be dictated by the use cases and ergonomic factors. Beyond simple stuff (e.g., the guidance given in WebIDL, like don't use numeric constants), there may not be much more that can be done. If anything, the TAG should be telling people to think really critically about API design and developer ergonomics - road test APIs, get feedback, etc. and not just blindly copy patterns from each other. So maybe what is needed is some explanation of why things are the way they are in the platform (warts and all).  

But I don't know. Maybe all those people that said that IndexedDB sucks have an idea how it could have been done better? People like Yehuda, who is on the JQuery team, might have some ideas about assessing the usability (and non-suck aspect) of an API.  

> Other than that, I believe it is well within the rights of individual  
> W3C WGs to publish APIs that meet the needs of the WG members.

This seems counter to the W3C's primary goal:

"The social value of the Web is that it enables human communication, commerce, and opportunities to share knowledge. One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability." - http://www.w3.org/Consortium/mission.html

If members were only serving their own interests, many of the things above would not be addressed. To illustrate, the above is at the core of why so many people are up in arms about DRM. But please lets not have a DRM discussion here.   

> Opinions  
> of taste run secondary to those needs, but I'm sure that should good  
> advice be given, WGs would at least listen to it.

Um, the needs are generally: "we want to make an API to allow X that people will want to use".

If you then say, "oh, we don't care if the developers don't like it", then you probably are going to have some pretty serious problems (specially when there are lots of platforms competing for developer mindshare).  

The *happy* developer should be at the forefront of every API decision. We make APIs for people to use, and *secondarily* to solve some problem. Without the developer using it (or if the developer can't use it), then you can't actually solve the problem the API was designed to address.  
> I guess there is another possible TAG-level issue: just how many APIs  
> are needed for access to local data storage?

Yes, that is another big issue (particularly with that Alarm API… it introduces yet another persistent database into the Web platform, which equals more security and privacy considerations that need to be dealt with).

Received on Thursday, 7 February 2013 16:39:36 UTC