Re: On scoping and modularity

Dom,

I agree that, broadly speaking, the ORTC development is a lot more 
productive than that of WebRTC.

The community seems a lot more unified than this one (here, we've got 
two sizable camps with opposing views).
Many of the members are active participants (here, people mostly chime 
in to voice their disagreement but are otherwise passive).

I think both of the above factors are working strongly against us and in 
my opinion they have resulted in a sub-par API. At a high level, it 
feels like people have given up on doing anything more than releasing 
what we have, as opposed to making sure it's actually worth releasing. I 
think this is understandable in light of the fact that the rate of 
WebRTC deployment has outstripped the rate of the API design by such a 
large factor. Compare this to the rate of API design going on on the 
ORTC mailing list to see what I mean.

As for what can be done to improve this situation... well :) Cut this 
project in half. At least then you'd have a more unified community ;) I 
think it's better to put out smaller high-quality releases in an 
incremental fashion than throwing something over the fence out of 
reluctance. What is planned for 1.0 is not "smaller". It's "what we 
already have". By smaller I mean we should put out a tiny subset of the 
current API that is good enough to build an application on top of, and 
is well designed, and everyone can more or less agree on. In this model, 
you will need to invest more thought into forward-compatibility (which I 
think is actually a good thing).

Gili

On 23/04/2014 12:09 PM, Dominique Hazael-Massieux wrote:
> Hi,
>
> Back on January, we started a useful but somewhat difficult discussion
> on our path to "WebRTC 1.0"; for various reasons, including our need to
> move forward with constraints in getUserMedia, further discussion on the
> topic has stalled.
>
> There are several reasons that makes this discussion still (and probably
> even more) important, so I would like to propose to re-open it, with a
> proposed way forward, while also trying to appease some of the worries
> that I heard during our previous attempt, based on my experience with
> the development and adoption of Web APIs.
>
> First, the reasons I think we need to have that discussion are:
> * we started the standardization efforts on WebRTC 3 years ago; none of
> our specs have reached last call, even though an already impressive and
> growing number of products rely on our technologies. Unless we make an
> explicit effort to finalize and freeze the technologies that are already
> in wide use and deployment, we will keep adding bits of new features
> here and there, leaving the market under bewilderment as to what may
> change under their feet (a regular complaint I've gotten from product
> managers at WebRTC conferences)
>
> * it was brought to my attention that the dashboard that sets Internet
> Explorer roadmap [1] indicates that WebRTC 1.0 is “not currently
> planned”, while an ORTC-based version of the API (assuming it would form
> the basis of a 2.0 version) is “under consideration”; while there can be
> debates about the exact interpretation of that dashboard, when combined
> with the abundant critical feedback we've gotten on the reliance of the
> current API on SDP and offer/answer, I think there is a clear need for
> the group to be able to move to the next iteration of some of the pieces
> of the API; but we can't possibly do that until we finish the current
> work, and we can't finish it if we don't set ourselves a limited scope.
>
> 1. http://status.modern.ie/webrtcwebrtcv10api
>
> I guess the first thing we would need to get consensus on as a group is
> that we need to determine the scope of our 1.0 efforts, and that we need
> to determine it now.
>
> Assuming there is such a consensus (which is not proven yet), then we
> will need to get consensus on what this 1.0 scope is.
>
> Determining this is probably more tricky; my personal view, informed by
> the thread we had back in January on what developers out there need from
> us, is that we should basically finalize what is already implemented or
> being implemented today; at a first approximation, this would mean
> mostly what is in the current WebRTC specification. In other words, my
> suggestion would be that we explicitly agree not to add new features in
> the existing specification.
>
> Now, we have already identified features that we know we want sooner
> rather than later, especially around optimizing the integration with the
> protocols stack.
>
> My proposal would still be that we don't include these additions to the
> main specification (since they are by definition much less mature), and
> instead develop them as separate modules.
>
> I have mentioned using modularity to help us manage our focus and
> schedule a few times, and heard generally the following arguments
> against it:
> * putting a feature in a module means it will be implemented later, or
> not at all, and risks actually killing it
>
> * creating a module is costly specification-wise and may create gaps
>
> On the implementation aspect, my experience shows that, for better or
> for worse, the document in which a given feature is specified as little
> or no bearing on the implementors decision to adopt the said feature.
> Implementors always end up deciding what they implement based on the
> needs they see in their market, almost never based on what a
> standardization group sets. So putting a feature in the "main" spec or
> in a module has pretty much no effect on whether the feature will be
> adopted or not, and each feature needs to demonstrate its usefulness and
> appeal on its own, no matter where it spec'd.
>
> On the editorial side, I'll easy admit that modularity doesn't come
> cost-free; but in the priority of consistuencies [2], the cost to
> specifiers come well below the cost to developers, and we've heard loud
> and clear from developers that what they need the most at the moment is
> stability and polishing of existing features. If that means we need to
> put more efforts in achieving that goal, that's a reasonable cost to
> endure, and I'll be happy myself to contribute to the efforts that
> bringing more modularity requires.
>
> I'm interested in feedback both on the need to scope our 1.0 work, and
> on the proposed scope I'm suggesting in this message.
>
> Dom
>
> 2.
> http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
>
>
>

Received on Wednesday, 23 April 2014 18:20:34 UTC