Re: Use cases and reqs

So this topic is really no different than any any other topic we are trying to decide. One way would be to have use cases, then start on requirements,  from agreed on requirements make specs, then example code. I basically hate the waterfall method to developing things like this - I think that it is faster and easier to understand if all theses things proceed in parallel. For pretty much any decision, I like what I am seeing on the list now, people are proposing use cases and requirements and around the same time thinking about what it might look like in a spec, how the API would be structured and what it would be like to use it with perhaps some example code.  I completely agree that we should not be adding stuff into the API for which we did not have a solid use case - for this topic or any other. I also agree that we are not going to solve all the use cases in the first version of the spec. However, deciding what to put in or leave out is easier as you understand how hard it would be to add later, and how important the use cases are around it. Some things we identify and decide too leave out may still influence the extensibility points we leave in the API. In the same way we are interactively developing multiple things at the same time in webrtc, we need to keep in sync with parallel work about the over the wire protocol in rtcweb. 

So should we only do things we have use cases for, definitely support that. Should we not boil the ocean, Yes of course. But lets not do waterfall development.

On the topic of use case documents, it seems to me that the webrtc and rtcweb WG pretty much should be using more or less the same use case document. Any thoughts on that? 


On Jul 18, 2011, at 23:10 , Stefan Håkansson LK wrote:

> All,
> 
> there has been some discussion lately on the list related to enabling the application to hint to the browser certain properties of the media scene (audio/voip, video resolution, video frame rate, ....).
> 
> You may also have noted that I (in my individual contributor role) has been a bit negative; I advocate that we should do something simple without such support in the API and add it later if practical use shows there is a real need.
> 
> However, I think the correct way to handle this should be to add use cases (and I think such use cases have been described in postings to this list) that such requirements are derived from and then in some ordered fashion discuss and decide between rtcweb and webrtc if those use cases/requirements should be prioritized for version 1 of the specs.
> 
> Would this be an agreeable way to move forward?
> 
> How should this be brought up with the rtcweb WG?
> 
> Stefan


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

Received on Tuesday, 19 July 2011 22:33:40 UTC