Issue 26931002: Define Cast Content API

Issue 26931002: Define Cast Content API (Closed)

Created:
7 years, 2 months ago by Alpha Left Google

Modified:
7 years, 2 months ago

Reviewers:
jam

CC:
chromium-reviews, joi+watch-content_chromium.org, darin-cc_chromium.org

Base URL:
svn://svn.chromium.org/chrome/trunk/src

Visibility:
Public.

More Reviews

Description

Define Cast Content API Cast Content API is defined under content/public/renderer as an interface between chrome extensions and WebRTC/Cast implementations in content renderer. This interface contains following two functional classes: WebRtcCastSendTransport This is the main entry point of Cast API. This interface is responsible for configuring and control a cast stream. This includes assigning a MediaStreamTrack as source, set parameters and start/stop the stream. WebRtcUdpTransport This interface is responsible for setting up the network connection. It is used to bind to a network socket and connect to a remote address for cast. BUG=301920

	Unified diffs	Side-by-side diffs	Delta from patch set	Stats (+232 lines, -0 lines)			Patch
M	chrome/chrome_renderer.gypi	View	1 2 3	1 chunk	+6 lines, -0 lines	0 comments	Download
A	chrome/renderer/media/cast_send_transport.h	View	1 2 3	1 chunk	+109 lines, -0 lines	0 comments	Download
A	chrome/renderer/media/cast_send_transport.cc	View	1 2 3	1 chunk	+66 lines, -0 lines	0 comments	Download
A	chrome/renderer/media/cast_udp_transport.h	View	1 2 3	1 chunk	+30 lines, -0 lines	0 comments	Download
A	chrome/renderer/media/cast_udp_transport.cc	View	1 2 3	1 chunk	+21 lines, -0 lines	0 comments	Download

Messages

Total messages: 10 (0 generated)

Expand Messages | Collapse Messages

Alpha Left Google

Please review. This API is all we need for Cast Extensions API.

7 years, 2 months ago (2013-10-10 23:20:48 UTC) #1

jam

so, just to be clear, you're sure you won't need anything else in the public ...

7 years, 2 months ago (2013-10-11 16:47:13 UTC) #2

Alpha Left Google

> so, just to be clear, you're sure you won't need anything else in the ...

7 years, 2 months ago (2013-10-11 20:24:21 UTC) #3

jam

On 2013/10/11 20:24:21, Alpha wrote: > > so, just to be clear, you're sure you ...

7 years, 2 months ago (2013-10-11 20:31:33 UTC) #4

Alpha Left Google

On 2013/10/11 20:31:33, jam wrote: > On 2013/10/11 20:24:21, Alpha wrote: > > > so, ...

7 years, 2 months ago (2013-10-11 21:42:59 UTC) #5

Alpha Left Google

> > so my motivation was to see all the APIs that are needed to ...

7 years, 2 months ago (2013-10-11 22:05:09 UTC) #6

Alpha Left Google

Above is my high level understanding now. Since all of webrtc is implemented in content ...

7 years, 2 months ago (2013-10-11 22:13:02 UTC) #7

jam

so in general, we only put stuff in content if it's required for the web ...

7 years, 2 months ago (2013-10-11 23:55:32 UTC) #8

Alpha Left Google

On 2013/10/11 23:55:32, jam wrote: > so in general, we only put stuff in content ...

7 years, 2 months ago (2013-10-12 00:42:49 UTC) #9

On 2013/10/11 23:55:32, jam wrote:
> so in general, we only put stuff in content if it's required for the web
> platform. for a chrome feature, i.e. something for extensions, we only put the
> bare minimum in content that chrome needs.
> 
> if this feature is planned to be exposed as a web platform feature, then it
> seems the way to implement this would be to have more code in blink (i.e. the
> bindings) and content. then chrome extensions code can enable it at runtime.
> 
> however it seems a bit odd to say that this is going to be a web platform
> feature, but the implementation is going to be spread across content and
chrome.

Eventually we want this to be part of the web platform. That's why we plan that
most
of the implementation to be done in content. Chrome extensions is just an
interface
(bindings) to expose to JS. The code there is really minimal and just interface
with
the Content API.

Like I mentioned before all of WebRTC is implemented in content. Cast API is
going
to be deeply interacted with WebRTC in implementation. So I think it's odd the
other
way that we implement Cast API in chrome and expose WebRTC interfaces. I makes
more sense to me Cast should be implemented next to WebRTC and only the high
level interface is exposed to Chrome as content API.

We have not started the standardization effort. Putting bindings in blink at
this
time will not be acceptable. But we do want to ship this in a product for Cast
in the
short future. Hence we chose Extensions API as the host for the bindings.

> 
> in your comment #6, which parts of P2PSocketClient need to be exposed?
> that entire header?

The public interface of P2PSocketClient will have to be exposed. This means
Init(),
Send(), Close(). 

> does the delegate?

The delegate has to be expose as well since content needs an interface to call
to
the implementation in chrome.

> what about the getters?

Getters are probably not needed.

> do you have a rough
> approximation of what the encryption module interface would look like?

Unfortunately we're still defining the requirements for encryption so I don't
have
an estimate for this low level interface.

> it's very hard for me to figure out where this code goes without these
answers.
> i still don't even know what interfaces would be needed to be added to content
> if this code lives there.

I think we need to expose some interface to content. Either it is exposed as a
high
level web feature like I proposed. Or it is exposed as a set of low level APIs
implemented by content.

If we go for the high level route then we only need two more interfaces similar
to:

class WebRtcCastDelegate {
 public:
  virtual void OnStarted() =0;
  virtual void OnConnected() = 0;
  virtual void OnStopped() = 0;
  virtual void OnError() = 0;
  virtual void OnTimeout() = 0;
  virtual void OnStats(std::vector<std::pair<std::string, std::string> > stats)
= 0;
  virtual void OnTraceEvents(std::vector<std::string> trace_events);
}

class WebRtcCastSendTransport {
 pubilc:
  // Allow install of delegate.
  static WebRtcCastSendTransport* Create(WebRtcCastDelegate*);

  // New method to enable tracing.
  virtual void EnableTracing(bool enabled) = 0;
}

// This I'm just guessing because it's very far off for encryption.
class WebRtcDtlsTransport {
 public:
  static WebRtcDtlsTransport* Create(WebRtcCastDelegate* delegate,
WebRtcUdpTransport* transport) = 0;
  virtual net::X509Certificate* GetRemoteCertificate() = 0;
  void Start();
  void Stop();
}

Closing this issue per our discussion.

Expand Messages | Collapse Messages