Re: [PresentationAPI] Intend to implement

[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

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-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Boris Zbarsky]

>> dictionary AvailableChangeEventInit : EventInit {
>> boolean available;

This needs a default value.

>> interface SocketChannelWithATwist { // temporary name

Should this inherit from EventTarget? Seems like it, given the
EventHandler attributes it has. Or does it not trigger those via
dispatching events to itself?

Will this be implemented behind a preference or some other means of
disabling it by default?

-Boris

[Kilik kuo]

Boris Zbarsky於 2014年9月8日星期一UTC+8下午11時51分04秒寫道：

> >> dictionary AvailableChangeEventInit : EventInit {
>
> >> boolean available;
>
>
>
> This needs a default value.

I'm not quite sure about this,
Since it's an optional argument for AvailableChangeEvent.
I assume it would be used in the scenario when controlling page is created after the presenting page has already notified its availability.
So the UA of controlling page should be able to discover 2nd screen by itself, and synthesize a signal to notify the availability.

>
>
>
> >> interface SocketChannelWithATwist { // temporary name
>
>
>
> Should this inherit from EventTarget? Seems like it, given the
>
> EventHandler attributes it has. Or does it not trigger those via
>
> dispatching events to itself?
>

Yes, I missed it !
This interface should inherits from EventTarget.
Will be added :)

>
>
> Will this be implemented behind a preference or some other means of
>
> disabling it by default?
>

Yes, sure.
There will be a preference like [Pref="dom.presentation.enabled"] to control the ability. And it will be disabled by default

>
>
> -Boris

It's really nice to get feedback from you, Boris.
Thanks :)

[Boris Zbarsky]

On 9/9/14, 2:57 AM, Kilik kuo wrote:
> Boris Zbarsky於 2014年9月8日星期一UTC+8下午11時51分04秒寫道：

>>>> boolean available;
>>
>> This needs a default value.
>
> I'm not quite sure about this,

I am. ;)

> Since it's an optional argument for AvailableChangeEvent.

Right, and the question is: what is the behavior when the argument is
not passed?

If you give this a default value, then that default value will be used.
If you don't given a default value, you have to define the behavior in
some other way.

The current trend in event specs is to use default values for things
that are optional.

-Boris

[Kilik kuo]

One more thing,

We would like to support URL of app scheme for requesting session.
And the scope will be as below.
- Certified and Privileged with declaration of origin apps are supported.
- Privileged apps w/o declaration of origin are NOT supported.
- Remote UA will launch the URL of app scheme only when this app is already installed on device. Once URL of packaged hosted app is landed, remote UA can launch installed app via the URL of http scheme.
(Maybe the 1st version of API will support app scheme for certified app only)

Is there any concerns or suggestions?
Any feedback is appreciated.
Thanks :)

[Ehsan Akhgari]

On 2014-09-15, 5:47 AM, Kilik kuo wrote:
> One more thing,
>
> We would like to support URL of app scheme for requesting session.
> And the scope will be as below.
> - Certified and Privileged with declaration of origin apps are supported.
> - Privileged apps w/o declaration of origin are NOT supported.
> - Remote UA will launch the URL of app scheme only when this app is already installed on device. Once URL of packaged hosted app is landed, remote UA can launch installed app via the URL of http scheme.
> (Maybe the 1st version of API will support app scheme for certified app only)

I'm not sure if I understand how a remote UA is supposed to render an
app:// URL coming from a privileged app?

[Fabrice Desré]

The app needs to be installed on both UAs, but to ensure we have a common
origin on both sides, only apps that declare their origin will be
supported. I'd like us to get packaged hosted apps done instead of
needing to support this, so I think this should be relatively low
priority.

Fabrice

[Marco Chen]

Hi,

According to our first version will be enabled on FxOS with Certified apps only,
to enable/support "app://" can allow us to add values into Certified apps by this API.

ex: An addon for desktop Firefox browser can launch an corresponding app in remote TV.
Then you can fling what movie you are watching to TV and control it by desktop Firefox browser.

For packaged hosted app, I think it will be privileged app type at most.
So it will be relatively low priority indeed until this API is mature enough to be exposed to privileged.

Sincerely yours.
----- Original Message -----

_______________________________________________
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Ehsan Akhgari]

Does this mean that now the URLs in certified gaia apps must be
considered stable? i.e., if the dongle is running version X of gaia and
the device is running version X+1, are URLs from version X+1 guaranteed
to exist and work the same way on version X? Have gaia developers been
notified about this?

On 2014-09-16, 7:07 AM, Marco Chen wrote:
> Hi,
>
> According to our first version will be enabled on FxOS with Certified apps only,
> to enable/support "app://" can allow us to add values into Certified apps by this API.
>
> ex: An addon for desktop Firefox browser can launch an corresponding app in remote TV.
> Then you can fling what movie you are watching to TV and control it by desktop Firefox browser.
>
> For packaged hosted app, I think it will be privileged app type at most.
> So it will be relatively low priority indeed until this API is mature enough to be exposed to privileged.
>
> Sincerely yours.
> ----- Original Message -----
>
> From: "Fabrice Desré" <fab...@mozilla.com>
> To: dev-pl...@lists.mozilla.org
> Sent: Tuesday, September 16, 2014 1:20:58 PM
> Subject: Re: [PresentationAPI] Intend to implement
>

[Marco Chen]

Hi Ehsan,

That is a good question and I didn't think about it.

> are URLs from version X+1 guaranteed to exist

The requestSession() returns a promise then this promise will be rejected if that URL is not existed on remote UA.
Also there is a discussion on webscreen mail list to check whether we can apply condition (ex: URL) then UA will filter out screens not support this URL.

> work the same way on version X?

This is really an issue and what I can imagine is
1. the X+1 should be backward compatible
2. or UA can filter out if the API version is different.

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

寄件者: "Ehsan Akhgari" <ehsan....@gmail.com>
收件者: "Marco Chen" <mc...@mozilla.com>, "Fabrice Desré" <fab...@mozilla.com>
副本: dev-pl...@lists.mozilla.org
寄件備份: 2014 9 月 16 星期二 下午 11:01:36
主旨: Re: [PresentationAPI] Intend to implement

Does this mean that now the URLs in certified gaia apps must be
considered stable? i.e., if the dongle is running version X of gaia and
the device is running version X+1, are URLs from version X+1 guaranteed
to exist and work the same way on version X? Have gaia developers been
notified about this?


On 2014-09-16, 7:07 AM, Marco Chen wrote:
> Hi,
>
> According to our first version will be enabled on FxOS with Certified apps only,
> to enable/support "app://" can allow us to add values into Certified apps by this API.
>
> ex: An addon for desktop Firefox browser can launch an corresponding app in remote TV.
> Then you can fling what movie you are watching to TV and control it by desktop Firefox browser.
>
> For packaged hosted app, I think it will be privileged app type at most.
> So it will be relatively low priority indeed until this API is mature enough to be exposed to privileged.
>
> Sincerely yours.
> ----- Original Message -----
>
> From: "Fabrice Desré" <fab...@mozilla.com>
> To: dev-pl...@lists.mozilla.org
> Sent: Tuesday, September 16, 2014 1:20:58 PM
> Subject: Re: [PresentationAPI] Intend to implement
>

[Ehsan Akhgari]

On 2014-09-16, 11:13 AM, Marco Chen wrote:
> Hi Ehsan,
>
> That is a good question and I didn't think about it.
>
> > are URLs from version X+1 guaranteed to exist
> The requestSession() returns a promise then this promise will be
> rejected if that URL is not existed on remote UA.
> Also there is a discussion on webscreen mail list to check whether we
> can apply condition (ex: URL) then UA will filter out screens not
> support this URL.

That would mean presumably figuring out whether that URL resolves to
anything, right? But note that we are talking about whether the URL
resolves to the same semantic resource. For example, if /foo shows a
video in Gaia X and just shows a preview in Gaia X+1 and redirects to
/foo/play to play the video, sending the fling to /foo will "work"
because /foo is a valid URL on both sides, but doesn't do the right
thing (play the video) as far as the user is concerned.

> > work the same way on version X?
> This is really an issue and what I can imagine is
> 1. the X+1 should be backward compatible
> 2. or UA can filter out if the API version is different.

I think both of those solutions have downsides, but unfortunately I
don't know enough about the goals we're trying to achieve here to be
able to give a useful suggestion. :( But it's at least something to
keep in mind.

> ------------------------------------------------------------------------
> *寄件者: *"Ehsan Akhgari" <ehsan....@gmail.com>
> *收件者: *"Marco Chen" <mc...@mozilla.com>, "Fabrice Desré"
> <fab...@mozilla.com>
> *副本: *dev-pl...@lists.mozilla.org
> *寄件備份: *2014 9 月 16 星期二 下午 11:01:36
> *主旨: *Re: [PresentationAPI] Intend to implement

>
> Does this mean that now the URLs in certified gaia apps must be
> considered stable? i.e., if the dongle is running version X of gaia and
> the device is running version X+1, are URLs from version X+1 guaranteed
> to exist and work the same way on version X? Have gaia developers been
> notified about this?
>
>
> On 2014-09-16, 7:07 AM, Marco Chen wrote:
> > Hi,
> >
> > According to our first version will be enabled on FxOS with Certified
> apps only,
> > to enable/support "app://" can allow us to add values into Certified
> apps by this API.
> >
> > ex: An addon for desktop Firefox browser can launch an corresponding
> app in remote TV.
> > Then you can fling what movie you are watching to TV and control it
> by desktop Firefox browser.
> >
> > For packaged hosted app, I think it will be privileged app type at most.
> > So it will be relatively low priority indeed until this API is mature
> enough to be exposed to privileged.
> >
> > Sincerely yours.
> > ----- Original Message -----
> >
> > From: "Fabrice Desré" <fab...@mozilla.com>
> > To: dev-pl...@lists.mozilla.org
> > Sent: Tuesday, September 16, 2014 1:20:58 PM
> > Subject: Re: [PresentationAPI] Intend to implement
> >