1143996 - (webcast) [Meta]Web-cast

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Junichi Hashimoto]

As an end-user, I'd like to share what is on top of the screen with another device just by touching devices.

As a developer, I'd like to make communication programs for devices in the web standard manner, i.e., http-based client-server model, without concerning lower layer such as network establishment.

* The functionality should not require certified APIs.
* The contents are for example, homepage URL, still image, video streaming, music, presentation document or games.
* Server libraries should be provided for this purpose and maintained.
* User experience should be consistent for any sharing.

Comment 1

[Tomoaki Konno]

I think web server functionality is mandatory for web-cast, but the server library is one of the options to provide user with the above experience.

Comment 2

[Junichi Hashimoto]

Attachment: architecture

Comment 3

[Sandip Kamat]

User story updated

Comment 4

[Junichi Hashimoto]

Attachment: webcast-manager.zip

Comment 5

[Junichi Hashimoto]

Attachment: webcast-player.zip

Comment 6

[Junichi Hashimoto]

Two apps demonstrate how webcast is expected to work.
(Apps are tested on the latest FxOS/Nexus4)

Usage:
0. enable wifi-direct by [1] and enable NFC
1. install manager and player on device A, and install manager on device B
2. launch player app on A
3. tap devices. you'll see the browser is launched on B

[1] https://gist.github.com/justindarc/1d88d7d14e3264e8a666

Note:
- The player doesn't have a server inside so nothing will be shown on the browser.
- The manager should be merged into the system app.

Although I described that the webactivity for network information after peerfound event is received, peerlost is fired before the response returns and NFC message is not able to be sent.
So I divided the request into two; one is purely for getting network information. This is expected to be requested before touch. Another one is for asking wifi-direct initiation and this is requested when you touch devices.

Comment 7

[Vincent Chang[:vchang][changyihsin]]

Guillaume, want to review proposed webcast architecture in comment 6 by Kddi. Any feedback is welcome.

Comment 8

[Sandip Kamat]

Adding Vincent's link for notes: https://github.com/changyihsin/Notes/blob/master/note.md

Vincent - best to move that discussion to this bug I think

Comment 9

[Justin D'Arcangelo [:justindarc]]

A conversation has recently begun in Bug 1159774 for implementing HTTP background server processes.

Additionally, here is a MozHacks article I wrote a few months back regarding an HTTP server implementation I did for Firefox OS:

https://hacks.mozilla.org/2015/02/embedding-an-http-web-server-in-firefox-os/

fxos-web-server:
https://github.com/justindarc/fxos-web-server

Comment 10

[Ben Francis [:benfrancis]]

Perhaps I've misunderstood but isn't part of this what the Presentation API is supposed to be for? http://w3c.github.io/presentation-api/

It doesn't require that every client also be a server.

Comment 11

[Vincent Chang[:vchang][changyihsin]]

Per offline talk with schien, there might be some security concerns about using presentation APIs. NI? schien for more detail information.

Comment 12

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Presentation API suits well for displaying things on remote display. However we still need to provide a URL for remote device accessing the local files, which means we still need a local server. Data URL could be a server-less workaround but not scaled for large file.

Comment 13

[Vincent Chang[:vchang][changyihsin]]

(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #12)
> Presentation API suits well for displaying things on remote display. However
> we still need to provide a URL for remote device accessing the local files,
> which means we still need a local server. Data URL could be a server-less
> workaround but not scaled for large file.

In case of webcast, the URL can be exchanged via NFC NDEF message when two devices are proximity.

Comment 14

[ju-hashimoto]

Attachment: Activity Diagram

Basic activity of host(sender, server) and guest(receiver, client)

Comment 15

[ju-hashimoto]

Attachment: State machine of webcast manager (Diagram)

State machine diagram of webcast manager
"Guest" state and "Host" state have internal states.

Comment 16

[ju-hashimoto]

Attachment: State machine of webcast manager (Table)

State machine table of webcast manager

Unstableness of webcast-manager.zip and webcast-player.zip seems to be caused by unexpected state transitions e.g., taping again during p2p-connection. Careful review on the state machine is required.

Comment 17

[(inactive after 6/18) Alive Kuo [:alive]]

My 2$:

1. Is there any UI in WebcastManager? If not, can we put it in gecko? I don't see a good reason to route such a platform detail to system app. It seems redundant.
2. WebActivity should be anonymous. You cannot assume there is only one consumer for 'webcast-ready' activity. i.e., we should not use WebActivity here to do the communication.
3. What's the fallback plan if the client side (device B) has no player?
4. What's the difference of sharing image with shrinking UI here..... ?

Comment 18

[ju-hashimoto]

Hi,

1. At least, a user wants to turn manager On or Off. It is in gaia layer. (Do I answer your question?)
2. I agree with you. Inter App communication API was an alternative. But to keep web-cast accessible from privileged app, we cannot use the API.
3. The fallback is the browser.
4. With web-cast, we can design the presentation. e.g., slideshow, folder share.

Comment 19

[Junichi Hashimoto]

Attachment: Activity Diagram

Activity order is corrected and indicator numbers(G1-G6, H1-H3) are added.

Comment 20

[Junichi Hashimoto]

Attachment: 0602webcast-player.zip

Comment 21

[Junichi Hashimoto]

Attachment: 0602webcast-manager.zip

Some bugs are fixed and the flow is now align to the Activity Diagram.

Comment 22

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Who on top of system app would like to review the state machine?

Comment 23

[Greg Weng [:snowmantw][:gweng][:λ]]

I feel quite confused to suddenly be asked a review while I was completely out of this thing. Not to mention you seem not to want to specify me, but just try to find "who" could review this patch. Normally, we asked modules owners if we don't really know who should review this; but in this case you neither info me about anything before this no matter online or offline, nor asked module owners' opinions. That is just so...weird? Did anyone or I give you the wrong information about the roles my colleagues and me in the future? Because as far as I know, the discussion is just ongoing and I heard no final desicion yet. It would be appreciated if you could explain the thing more clear. Maybe you could find me at work week.

Comment 24

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

You're right. I should ping Tim first.

Comment 25

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I can't answer any question without seeing the code, and the code shouldn't live inside a zip file.

We have a clear guidance in place for contribution. Please read the docs (and links in the docs) below. Thanks!

https://github.com/timdream/gaia/blob/master/CONTRIBUTING.md

Comment 26

[Junichi Hashimoto]

In a sync up vidyo call, we've decided to review state-machine design before making patch from the zip.
Do you mean to skip the step?

Comment 27

[Guillaume Marty [:gmarty]]

I made a review of the specs and manager/player apps, here are some questions/remarks:

1. The architecture proposed looks good to me. But I'd like to know more about the NDEF message, specifically the part when both devices are on the same network and doesn't use Wifi Direct.
2. As Tim said, reviewing outside of Github is hard. I understand that we agree to work that way, but we probably need to revise this decision.
3. As per comment 6 by Junichi-san above, the manager should live in the system app. I think that's better to start working directly on the system app. I can help you with that.

Here are the things we need to do:
1. Land the code directly in the system app in a git branch.
2. Update the code to conform with Gaia coding style and standard.
3. Write unit and integration tests for webcast.
4. Finalise the server code in terms of API and integrate it in Gaia (based on https://github.com/justindarc/fxos-web-server). Ideally we need a high level API so that webcast and other apps can reuse the same service living in Gaia without conflicts (ports...). This should be done in a dependent bug.
5. Integrate webcast activities in Gaia apps (Gallery, video, music...). This can be done in subsequent bugs.

What do you think? Am I missing something?

Comment 28

[Junichi Hashimoto]

Perfect. Let's go forward along with your suggestion.

> 1. The architecture proposed looks good to me. But I'd like to know more
> about the NDEF message, specifically the part when both devices are on the
> same network and doesn't use Wifi Direct.

It's better to use WiFi Direct always.

There is no simple way to check both devices are able to communicate with each other.
Even if both are under the same SSID, direct communication is sometimes impossible or prohibited.

Comment 29

[Justin D'Arcangelo [:justindarc]]

(In reply to Junichi Hashimoto from comment #28)
> Perfect. Let's go forward along with your suggestion.
> 
> > 1. The architecture proposed looks good to me. But I'd like to know more
> > about the NDEF message, specifically the part when both devices are on the
> > same network and doesn't use Wifi Direct.
> 
> It's better to use WiFi Direct always.
> 
> There is no simple way to check both devices are able to communicate with
> each other.
> Even if both are under the same SSID, direct communication is sometimes
> impossible or prohibited.

Couldn't you just attempt an OPTIONS/HEAD HTTP request from one device to another? If you get an HTTP 200, then you'd know that direct communication is possible. It would be nice to be able to have a robust fallback mechanism in place for trying the current WiFi network first and then falling back to WiFi Direct.

Comment 30

[Junichi Hashimoto]

OK, I have two concerns.
1) If the check takes some seconds, it's quite bad for user experience.
2) The server doesn't know which network (wifi or wifi-direct) will be used,
so it always has to listen to new wifi-direct connection request.
The server has to stop this listening when the client gets access via wifi.

Comment 31

[BMO Automation]

Firefox OS is not being worked on