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
On 2014-09-07, 3:25 AM, ki...@mozilla.com wrote:
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.
_______________________________________________
dev-webapi mailing list
dev-web...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapi
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
