Introduce WebMediaSession

third_party/WebKit/public/platform/modules/mediasession/WebMediaSession.h

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef WebMediaSession_h
+#define WebMediaSession_h
+
+#include "public/platform/WebCallbacks.h"
+#include "public/platform/modules/mediasession/WebMediaSessionError.h"
+
+namespace blink {
+
+using WebMediaSessionCommandCallback = WebCallbacks<void, const WebMediaSessionError&>;
+
+class WebMediaSession {
+public:
+    virtual ~WebMediaSession() = default;
+
+    virtual void activate(WebMediaSessionCommandCallback*) = 0;
+    virtual void deactivate(WebMediaSessionCommandCallback*) = 0;

[mlamouri (slow - plz ping), 2015/10/07 14:19:31]

Why are we using a custom callback for deactivate() while we do not expect an
error? Should we have two type of callbacks:
- WebMediaSessionActivateCallback which will be <void, const
WebMediaSessionError&>
- WebMediaSessionDeactivateCallback which will be <void, void>

[davve, 2015/10/08 09:17:35]

As the code stands here, there's no probably no good reason. But when
building on this, I had a reason for going this way. For each activate
call, the plan is to generate an activate number for the IPC.

When the activate finishes, there is IPC back with the corresponding
activate number so that the render process can resolve the correct
promise.

We also need the corresponding infrastructure for deactivate(). No,
deactivate() can't fail but we still need to resolve the promise when
it has completed.

If the callback API for resolving activate() and deactivate() is the
same, we can use the same map. Something like in
WebMediaSessionAndroid:

  std::map<int, blink::WebMediaSessionCommandCallback*> commands_;

for outstanding activate and deactivate calls on the renderer side. If
the API is different we need a separate map for activate() and
deactivate().

It not super important but made the code a bit simpler later on.

[mlamouri (slow - plz ping), 2015/10/09 13:01:28]

I replied in the new patchset. I don't think we should have oddities because of
future plans. The change will be trivial when the requirements you are talking
about will apply. I would prefer to do that change when needed instead of having
something that doesn't sound useful now.

[davve, 2015/10/19 13:12:42]

Done.

+};
+
+} // namespace blink
+
+#endif // WebMediaSession_h