Re: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00

[Harald Alvestrand <[e-mail]>]

On 10/21/2011 03:00 PM, Hadriel Kaplan wrote:
> On Oct 21, 2011, at 7:40 AM, Harald Alvestrand wrote:
>
>> It also served very nicely to illustrate the breadth of functionality that a "low level API" needs to expose.
> Actually I'm 100% sure I've forgotten/missed some things it needs to expose.  BUT, some of the things I listed need to be exposed even for a ROAP model, yet for some reason aren't in the WG use-case-and-requirements draft; and some  already exist exposed in the current W3C draft I think.
I'm sure. The use cases are relatively high level, much higher level 
than the APIs and protocols.

For those you see missing, it would be a good exercise to follow the 
object to "how can I describe the use case in which this is essential", 
and see if it maps to any of the current use cases, or needs to be added.
We've  done several wrinkles on the use cases in order to expose a 
specific requirement - for instance, the need to operate when one or 
both of the participants is behind a NAT box or a 3G mobile connection.
>> One note (speaking as a W3C WG chair): While it's very nice to imagine that one can toss a task like "design an API" over to another organization and having it performed, in practice, the W3C functions much like the IETF; it's not a place where you throw work in order to get work done, it's a place where people who need the work done go to work on the problem.
>> But we all knew that, I think….
> Actually I don't know anything about the W3C.  What I meant in the draft by saying "it's really up to W3C" was that I thought it was highly presumptuous of us in the IETF to tell the W3C what to do as the API.  I figured they do APIs for a living, while IETF does protocols for a living. (which might explain why we're now talking in the IETF about defining a protocol as an API, eh? ;)
I think getting them right requires a huge amount of information 
exchange .... in the W3C community, I see arguments about the dearth of 
good API designers too, and designing an API without understanding the 
underlying technology is just very unlikely to succeed.

Luckily, we've got people (usually members of both lists) who are 
implementing this even as we speak; they might get enough feedback into 
the loop eventually.

                 Harald