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

On Feb 7, 2013, at 11:39 AM, Marcos Caceres wrote:

> 
> 
> 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™.

OK, I agree with you, but what do you want the TAG to do about this issue? Do you think "best practices" is a bad idea then? How would *you* solve the issue you raised?

> The problem is that the guidance could be misapplied

So what would you do about that?

> (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

Yes, but how?

> - 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.  

Are you planning to ask those people what the TAG could do about this issue?

> 
>> 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

That's certainly a W3C organizational goal.

> 
> If members were only serving their own interests, many of the things above would not be addressed.

The W3C seeks also to address the needs of its members. Often it is not clear when an API is begun whether it will "enable[s] human communication, commerce, and opportunities to share knowledge". That's why members decide to create an XG or WG and write a spec. They are often at the beginning phase of knowing whether their products based around the spec. will succeed.

> 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.   

DRM perfectly illustrates the potential tension between the needs of some W3C members and the W3C goal you mention above.

> 
>> 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".

Then why don't they?

> 
> 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.

Who is the happy developer though? Not all APIs are designed for the same developers.

> 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 agree that APIs have developers as customers. But they are designed to solve particular problems, or to perform particular tasks. Those tasks won't make *all* developers "happy" to use an API just because.

JohnK

>> 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:57:33 UTC