RE: Question about mandatory API in webrtc and mediacapture specs.

If the end goal is visibility for developers of apps on top of WebRTC, a more beneficial approach may be enumerating where things are compatible and where things aren't.  I suspect browser implementations will continue at an independent cadence.  I don't think roadmaps will be based off of a list of suggested mandatory and optional APIs.

Things are changing, but I've also seen certain underlying pieces which the browsers generate to be much more stable than a year ago (SDP blobs) come to mind.

-jim

From: Kiran Kumar [mailto:g.kiranreddy4u@gmail.com]
Sent: Monday, March 10, 2014 8:20 AM
To: James Spring
Cc: Cullen Jennings (fluffy); public-webrtc@w3.org; public-media-capture@w3.org
Subject: Re: Question about mandatory API in webrtc and mediacapture specs.

It is just to prioritize the API, that can be used by platform implementors temporarily (Until the spec is finalized). And the priority is to support
starting from basic audio-video call to extreme features that full-fill all the requirements and usecases of webrtc.
Mandatory IMHO gives the high priority while implementing the API. And Optional gives less priority where the API might not be stable or it might change in near future.


On Mon, Mar 10, 2014 at 8:30 PM, James Spring <jim.spring@skype.net<mailto:jim.spring@skype.net>> wrote:
What is your targeted use case for defining what should be in a mandatory API?  Different scenarios may require different aspects.

I also find it a bit odd to pick and choose from amongst the GetUserMedia API -- granted there are some recent changes proposed in the form of constraints and GetMediaDevices (I believe there is some concern around device/user fingerprinting with this particular call, but I can't pin point the email discussion).

-jim

On Mar 10, 2014, at 1:21 PM, Kiran Kumar <g.kiranreddy4u@gmail.com<mailto:g.kiranreddy4u@gmail.com>> wrote:


I don't think that the following API are mandatory for interoperability in regards to PeerConnection, but ofcourse few are required for some app to play with local mediastreams.
So I treated them as optional.


MediaStream:



clone<http://www.w3.org/TR/mediacapture-streams/#widl-MediaStream-clone-MediaStream> ();

DOMString             label<http://www.w3.org/TR/mediacapture-streams/#widl-MediaStreamTrack-label>;



MediaStreamTrack:



states<http://www.w3.org/TR/mediacapture-streams/#widl-MediaStreamTrack-states-MediaSourceStates> ();

clone<http://www.w3.org/TR/mediacapture-streams/#widl-MediaStreamTrack-clone-MediaStreamTrack> ();

boolean               enabled<http://www.w3.org/TR/mediacapture-streams/#widl-MediaStreamTrack-enabled>;

boolean               muted<http://www.w3.org/TR/mediacapture-streams/#widl-MediaStreamTrack-muted>;

boolean               _readonly<http://www.w3.org/TR/mediacapture-streams/#widl-MediaStreamTrack-_readonly>;



But it seems

MediaStreamTrackState<http://www.w3.org/TR/mediacapture-streams/#idl-def-MediaStreamTrackState> readyState<http://www.w3.org/TR/mediacapture-streams/#widl-MediaStreamTrack-readyState>;

should be in Mandatory



Thanks,

Kiran.

On Mon, Mar 10, 2014 at 6:30 PM, Cullen Jennings (fluffy) <fluffy@cisco.com<mailto:fluffy@cisco.com>> wrote:

Hmm - seem to me most of theses should be mandatory too

On Mar 10, 2014, at 5:51 AM, Kiran Kumar <g.kiranreddy4u@gmail.com<mailto:g.kiranreddy4u@gmail.com>> wrote:

> Mandatory API for Media Capture and Streams API
>
> Mandator API
> MediaStream:
>
> id;
> getAudioTracks ();
> getVideoTracks ();
> addTrack ();
> removeTrack ();
>
> MediaStreamTrack:
>
> getSourceInfos ();
> constraints ();
> capabilities ();
> applyConstraints ();
> stop ();
> getUserMedia ();
>
> DOMString             kind;
> DOMString             id;
> boolean               remote;
> Optional API
> MediaStream:
>
> getTrackById ();
> clone ();
> DOMString             label;
>
> MediaStreamTrack:
>
> states ();
> clone ();
> boolean               enabled;
> boolean               muted;
> boolean               _readonly;
> MediaStreamTrackState readyState;
>
> EventHandlers and callbacks are yet to be updated
>
>
>
>
> Thanks,
>
>
>
> Kiran.
>
>
> On Mon, Mar 10, 2014 at 4:34 PM, Kiran Kumar <g.kiranreddy4u@gmail.com<mailto:g.kiranreddy4u@gmail.com>> wrote:
> Hi,
> As discussed,  I prepared the following list for webrtc API.
>
> Mandator API
> createOffer ();
> createAnswer ();
> setLocalDescription ();
> setRemoteDescription ();
> updateIce ();
> addIceCandidate ();
> getLocalStreams ();
> getRemoteStreams ();
> addStream ();
> removeStream ();
> close ();
> createDataChannel ();
> insertDTMF ();
> getStats ();
>
> RTCSessionDescription? localDescription;
>
> RTCSessionDescription? remoteDescription;
>
> Optional API
>
> getStreamById ();
> RTCSignalingState      signalingState;
> RTCIceGatheringState   iceGatheringState;
> RTCIceConnectionState  iceConnectionState;
> boolean          canInsertDTMF;
> DOMString        toneBuffer;
> long             duration;
> long             interToneGap;
>
>  EventHandlers and callbacks are yet to be updated.
> Let me know your ideas and views to improve this.
>
> Thanks,
> Kiran.
>
>
> On Thu, Jan 30, 2014 at 7:26 AM, Kiran Kumar <g.kiranreddy4u@gmail.com<mailto:g.kiranreddy4u@gmail.com>> wrote:
> +1 for it to be in spec.
> If everyone agrees for it, I am happy to work on it.
>
> Thanks,
> Kiran.
>
>
> On Thu, Jan 30, 2014 at 6:42 AM, Cullen Jennings (fluffy) <fluffy@cisco.com<mailto:fluffy@cisco.com>> wrote:
>
> I think that needs to be (and hopefully is in) the specs.
>
>
> On Jan 28, 2014, at 7:05 AM, Kiran Kumar <g.kiranreddy4u@gmail.com<mailto:g.kiranreddy4u@gmail.com>> wrote:
>
> > Dear All,
> > Is there any plan to specification or wiki page to know which API's of webrtc and mediacapture specs are mandatory to implement in a browser and which of those are optional.
> >
> > Thanks,
> > Kiran.
>
>
>
>