[PresentationAPI] Intend to implement

[ki...@mozilla.com]

Hi dev.webapi,

We're intending to implement Presentation API for FxOS.
After checking
a) W3C CG final report [1]
b) W3C WG preparation [2]
c) Mailing list disucussed subject(Google/Mozilla Presentation API update) [3]

We may implement a draft version like the following first.
//////////////////////////////////////////////////////////
interface NavigatorPresentation : EventTarget {
PresentationSession startSession(DOMString url, DOMString sessionId);
PresentationSession joinSession(DOMString url, DOMString sessionId);

attribute EventHandler onavailablechange;
readonly attribute PresentationSession? session; // Only existed on presenting page
};

partial interface Navigator {
readonly attribute NavigatorPresentation presentation;
};

[Constructor(DOMString type, optional AvailableChangeEventInit eventInitDict)]
interface AvailableChangeEvent : Event {
readonly attribute boolean available;
};

dictionary AvailableChangeEventInit : EventInit {
boolean available;
};

enum PresentationSessionState { "connected", "disconnected" /*, "resumed" */ };

interface PresentationSession : EventTarget {
readonly attribute PresentationSessionState state;

SocketChannelWithATwist channel; // temporary name
attribute EventHandler onstatechange;
};

interface SocketChannelWithATwist { // temporary name
// The twist is that it's both a socket and a channel.
// Expose only serveral necessary properties we need in V1 and be compatible
// with RTCDataChannel/WebSocket.

void send((DOMString or Blob or ArrayBuffer or ArrayBufferView) data);
void close ();

attribute BinaryType binaryType;
readonly attribute unsigned long bufferedAmount;

// ready state
const unsigned short CONNECTING = 0;
const unsigned short OPEN = 1;
const unsigned short CLOSING = 2;
const unsigned short CLOSED = 3;
readonly attribute unsigned short readyState;

attribute EventHandler onmessage;
attribute EventHandler onopen;
attribute EventHandler onerror;
attribute EventHandler onclose;
};
//////////////////////////////////////////////////////////

There're 2 major changes regarding interfaces discussed between a) and c) above.
1. NavigatorPresentation API
- Using startSession/joinSession instead of requestSession with boolean flag "onlyReconnect". [4]
Having two functions with distinctive clear names.
- Exposing PresentationSession as a property of NavigatorPresentation, and dropping the EventHandler "onpresent" [5]
Easier for Web developers, as they don't need to race against the browser firing the onpresent event too soon before their event handler is registered.

2. PresentationSession object
- Using RTCDataChannel-like attributes instead of postMessage. [6]
Only several necessary attributes are introduced in v1 in case these v1 API becomes popular. And that would be backwards compatible to change the interface to RTCDataChannel in v2.

Thought the spec is not finally done yet, and there will be modifications in the future.
We hope that we could find out potential issues while doing this implementation.
Any suggestions or comments are greatly appreciated.

[1] W3C CG Final Report - http://webscreens.github.io/presentation-api/
[2] W3C WG Preparation - http://webscreens.github.io/charter/
[3] http://lists.w3.org/Archives/Public/public-webscreens/2014Aug/0003.html
[4] http://lists.w3.org/Archives/Public/public-webscreens/2014Aug/0046.html
[5] http://lists.w3.org/Archives/Public/public-webscreens/2014Aug/0058.html
[6] http://lists.w3.org/Archives/Public/public-webscreens/2014Aug/0028.html

Regards,
Kilik Kuo
Mozilla Taiwan.

[Ehsan Akhgari]

Hi Kilik,

Please note that the intent emails should be sent to dev-platform in
order to reach a wider audience. I'm leaving the full context below for
the benefit of the readers of that mailing list.

The proposal looks sane overall. I have one question though, is the
implementation going to be Firefox OS specific or is it going to be
shared across platforms?

Thanks!
Ehsan

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Jonas Sicking]

Hi Kilik,

I support implementing this API as described above, however I think we
need to keep it disabled in release builds for now. The API is still
not quite stable enough to ship and I expect some changes to be made
before the spec is ready.

Specifically, I expect the following to change:
* startSession/joinSession to return a Promise<PresentationSession> instead.
* The NavigatorPresentation.session API to change to support multiple
connected devices to a single TV.
* Anything else that we haven't thought of yet.

I still think it would be very valuable to implement the API that you
describe above. Not just because it means that we will have an easier
time to implement the final API. Also because it allows us to get some
experience with the API which can help inform the final API, and
because it's a good way to encourage people to arrive at the final
API.

Btw, have you looked at adding API to the <video> element to enable
displaying just a video element on a TV?

/ Jonas

[Kilik kuo]

Hi Ehsan,

In the long terms, this API should be shared cross platforms.
However, we're going to make it specific to FxOS by setting [Pref="dom.presentation.enabled"] & [AvailableIn=CertifiedApps] in the first version.

Regards,
Kilik

Ehsan Akhgari於 2014年9月8日星期一UTC+8下午11時38分04秒寫道：
> Hi Kilik,

[Ehsan Akhgari]

On 2014-09-09, 5:49 AM, Kilik kuo wrote:
> Hi Ehsan,
>
> In the long terms, this API should be shared cross platforms.
> However, we're going to make it specific to FxOS by setting [Pref="dom.presentation.enabled"] & [AvailableIn=CertifiedApps] in the first version.

The exact annotations that you should use in the IDL depends on the
semantics that you want to implement. If you use both of the above, for
example, the API will not be available on desktop and Android even if
the pref is set to true, and I doubt that is what you're looking to do.

Let me ask a different question: what environments would you like to
expose the API to initially before the spec is stable?

[Marco Chen]

Hi Ehsan,

> [Pref="dom.presentation.enabled"]
According to this API is not stable yet, we need to use annotation above to disable it on each platform first.

> [AvailableIn=CertifiedApps]
As I know that there are some non-standard (experimental) APIs can be used by certified apps,
we plan to enable this feature on FxOS and limited by certified permission.

I know that developers can manually set pref to true for using experimental API via about:config.
But in order to enable this pref to true on FxOS in default, we need to limit it by permission.
Or any suggestion for this?

Thanks,
Sincerely yours.
----- 原始郵件 -----

寄件者: "Ehsan Akhgari" <ehsan....@gmail.com>
收件者: "Kilik kuo" <kili...@gmail.com>, mozilla-d...@lists.mozilla.org
寄件備份: 2014 9 月 9 星期二 下午 11:19:47
主旨: Re: [PresentationAPI] Intend to implement

[Jonas Sicking]

I think we should make this API available to certified apps always,
and only to non-certified apps if the preference is set.

/ Jonas

[Ehsan Akhgari]

On 2014-09-09, 12:09 PM, Jonas Sicking wrote:
> I think we should make this API available to certified apps always,
> and only to non-certified apps if the preference is set.

I unfortunately don't think this is something that our existing WebIDL
annotations support. If you have both [Pref] and [AvailableIn], both
need to resolve to true for us to expose the API. So I think in this
case you would probably want to use a [Func] instead and write code for
this specific logic.