API scope

(resending — I send this two hours ago and it doesn't look like it made it to the list)

Hi all,

I think I heard a number of people during the F2F last week say that
they want to pack as many features in the spec as possible, for fear
that API delayed to a later version would never make it or make it too
late to be relevant.

While that approach is often reasonable for protocols, and sometimes for
formats, I don't think it's necessarily the better one for APIs:
* JavaScript APIs can be easily extended, by adding new properties,
interfaces, arguments in methods, etc

* the bigger the scope of the API, the more likely the interop will be
less good and/or the greater time it will take to get the API right

A lot of Web APIs have been more or less continuously evolving to take into
account new usage and new needs: the DOM and XMLHttpRequest are good
illustrations.

Arguably, it is much more problematic to have APIs that are too broad
than the contrary: it's more or less impossible to remove an API from
the platform once there are Web sites that start relying on it.

While we need to have a good idea on what future development of our
API(s) should look like, I also think we should resist the temptation to
push a lot of features into a first monolithic version of the API.
Alternatives include modularizing the features into independent or
complementary interfaces (using the tools that WebIDL provides for
that), or simply delaying less essential features to a later stage.

I don't have specific suggestions as to what features would need to be
modularized at this stage, but since there are quite a few proposals
under discussion (data channels, JSEP, capabilities/hints APIs, secured
media streams, ...), I thought it would be useful to share that
perspective.

Dom

Received on Monday, 6 February 2012 16:13:44 UTC