Closed Bug 1143996 (webcast) Opened 6 years ago Closed 3 years ago

[Meta]Web-cast

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

(feature-b2g:3.0?)

RESOLVED WONTFIX
feature-b2g 3.0?

People

(Reporter: xju-hashimoto, Unassigned)

References

Details

User Story

As a user, I would like to share a currently playing media on a FxOS device (image, video, contacts, URL) with another device (between Smartphones, tablets, TVs etc) using open standards / mechanism. NFC is used to automatically pair the device.

- Upon "Tap"(after necessary NFC settings enabled) the media starts playing on the second screen.
- All of the Media (+context) transfer & play happens using open standards (partner contributions)
- A kind of a client-server model to play files from where they are
- Content types: image, video, music, URL, presentation documents etc

Attachments

(6 files, 3 obsolete files)

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.
feature-b2g: --- → 3.0?
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.
Attached file architecture
User story updated
User Story: (updated)
Attached file webcast-manager.zip (obsolete) —
Attached file webcast-player.zip (obsolete) —
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.
Depends on: 1157657
Guillaume, want to review proposed webcast architecture in comment 6 by Kddi. Any feedback is welcome.
Flags: needinfo?(gmarty)
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
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
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.
Per offline talk with schien, there might be some security concerns about using presentation APIs. NI? schien for more detail information.
Flags: needinfo?(schien)
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.
Flags: needinfo?(schien)
(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.
Attached file Activity Diagram (obsolete) —
Basic activity of host(sender, server) and guest(receiver, client)
State machine diagram of webcast manager
"Guest" state and "Host" state have internal states.
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.
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..... ?
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.
Attached file Activity Diagram
Activity order is corrected and indicator numbers(G1-G6, H1-H3) are added.
Attachment #8612195 - Attachment is obsolete: true
Attached file 0602webcast-player.zip
Attachment #8590709 - Attachment is obsolete: true
Some bugs are fixed and the flow is now align to the Activity Diagram.
Attachment #8590707 - Attachment is obsolete: true
Who on top of system app would like to review the state machine?
Flags: needinfo?(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.
Flags: needinfo?(gweng) → needinfo?(whuang)
You're right. I should ping Tim first.
Flags: needinfo?(whuang) → needinfo?(timdream)
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
Flags: needinfo?(timdream)
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?
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?
Flags: needinfo?(gmarty)
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.
(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.
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.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.