976969 - Add TV module in gecko/dom

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[super-zou]

Attachment: 0001-add-dom-tv-module.patch

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Steps to reproduce:

Add TV module for firefox os;


Actual results:

1.the core of code implement in gecko/dom dir;
2.we just add tv api using webidl now, the real implement will commit soon;
3.make tv as an attribute of the navigator, app call it like this: navigator.tvManager
4.tv has some submodules, e.g, sound, pictue, channel. app call it like this:
navigator.tvManager.soundManager


Expected results:

we hope mozilla can accept these code as the standard of tv of firefox os.

Comment 1

[[:fabrice] Fabrice Desré]

We usually discuss APIs a bit (on the https://lists.mozilla.org/listinfo/dev-webapi mailing list) before landing massive patches.

Comment 2

[Ludovic Hirlimann [:Usul]]

(In reply to Fabrice Desré [:fabrice] from comment #1)
> We usually discuss APIs a bit (on the
> https://lists.mozilla.org/listinfo/dev-webapi mailing list) before landing
> massive patches.

after discussion , it's nice to ask reviews if you want your patch to be taken into account.

Comment 3

[super-zou]

we will provide dev-doc soon.

Comment 4

[super-zou]

have add a new topic in https://groups.google.com/forum/?hl=zh-CN#!topic/mozilla.dev.webapi/bRy0ECh_c-k,welcome you join.

Comment 5

[super-zou]

have add a new topic in 
https://groups.google.com/forum/?hl=zh-CN#!topic/mozilla.dev.webapi/bRy0ECh_c-k

Comment 6

[super-zou]

Attachment: TV-WebAPI-doc

Add dev webapi doc.

Comment 7

[(no longer active)]

Comment on attachment 8384445 [details]
TV-WebAPI-doc

This patch has not received any review.

Comment 8

[Gene Lian (I already quit Mozilla)]

Hi Super Zou, this is an awesome work but I'd like to clarify some points before moving forward.

1. I just quickly looked though the API proposal and it seems to me that the you're hoping to include all the TV-related functionalities into Web APIs in the first place, which are:

interface TVManager{
    [Throws] readonly attribute TVCiManager ciManager;
    [Throws] readonly attribute TVCommonManager commonManager;
    [Throws] readonly attribute TVScanManager scanManager;
    [Throws] readonly attribute TVSoundManager soundManager;
    [Throws] readonly attribute TVPictureManager pictureManager;
    [Throws] readonly attribute TVChannelManager channelManager;
    [Throws] readonly attribute DtvAudioInfo dtvAudioInfo;
};

Could you please give us some brief descriptions about these modules respectively? It's somehow difficult to guess the meanings by looking at the module/function names.

2. Do you have any concrete user cases about the need of these Web API from the apps' points of view? I'm asking this is I wonder some functions don't have to be public because the platform can just handle them internally. For example, why apps need TVScanManager to be able to scan the channels? Isn't that something the TV system can take care of during its initialization and the apps only need to know how to switch channels?

3. Regarding the TVSoundManager, since FirefoxOS is not just only designed for TVs, all the other devices that have speakers might need this function too. I think we somehow need to make these APIs more generic. We already had SpeakerManager[1] and AudioChannels[2] which might be a good entry point to start with. TVPictureManager might have the same issue, we probably need a more generic API to support various devices that have screens.

4. I'd suggest let's split up the modules into individual bug separately, it's hard to go through all the reviews (including Web IDL and implementations) in a single super big bug.

5. It's impossible keep the *TCL* terms as the enum names in the Web IDL. Web IDLs have to work for public.

[1] https://wiki.mozilla.org/WebAPI/SpeakerManager
[2] https://wiki.mozilla.org/WebAPI/AudioChannels

Comment 9

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Hi super-zou,

Thanks for contributing. Some comments about your patch:

 - The patch is quite large and thus hard to review. Maybe you can split it up into multiple pieces and get each piece reviewed individually. If possible, try to get the basic functionally reviewed first, and extras in separate patch later.

 - What are all these empty interfaces for? The comment says its for backward compatibility, but I don't expect that empty interfaces would make it through a review.

 - We'd really need some back-end code to make any use of this interface. There are Marionette test cases in the patch (they should be reviewed separately, btw) and it would be great to have a backend that's generic enough to do some testing in our emulator.

Comment 10

[super-zou]

(In reply to Gene Lian [:gene] (work week Mar. 5 ~ Mar. 7) from comment #8)
> Hi Super Zou, this is an awesome work but I'd like to clarify some points
> before moving forward.
> 
> 1. I just quickly looked though the API proposal and it seems to me that the
> you're hoping to include all the TV-related functionalities into Web APIs in
> the first place, which are:
> 
> interface TVManager{
>     [Throws] readonly attribute TVCiManager ciManager;
>     [Throws] readonly attribute TVCommonManager commonManager;
>     [Throws] readonly attribute TVScanManager scanManager;
>     [Throws] readonly attribute TVSoundManager soundManager;
>     [Throws] readonly attribute TVPictureManager pictureManager;
>     [Throws] readonly attribute TVChannelManager channelManager;
>     [Throws] readonly attribute DtvAudioInfo dtvAudioInfo;
> };
> 
> Could you please give us some brief descriptions about these modules
> respectively? It's somehow difficult to guess the meanings by looking at the
> module/function names.
> 
> 2. Do you have any concrete user cases about the need of these Web API from
> the apps' points of view? I'm asking this is I wonder some functions don't
> have to be public because the platform can just handle them internally. For
> example, why apps need TVScanManager to be able to scan the channels? Isn't
> that something the TV system can take care of during its initialization and
> the apps only need to know how to switch channels?
> 
> 3. Regarding the TVSoundManager, since FirefoxOS is not just only designed
> for TVs, all the other devices that have speakers might need this function
> too. I think we somehow need to make these APIs more generic. We already had
> SpeakerManager[1] and AudioChannels[2] which might be a good entry point to
> start with. TVPictureManager might have the same issue, we probably need a
> more generic API to support various devices that have screens.
> 
> 4. I'd suggest let's split up the modules into individual bug separately,
> it's hard to go through all the reviews (including Web IDL and
> implementations) in a single super big bug.
> 
> 5. It's impossible keep the *TCL* terms as the enum names in the Web IDL.
> Web IDLs have to work for public.
> 
> [1] https://wiki.mozilla.org/WebAPI/SpeakerManager
> [2] https://wiki.mozilla.org/WebAPI/AudioChannels

For Q1: We will write the doc followwing the format of WebAPI/SpeakerManager, it contains some brief descriptions and user cases.
For Q2: As a TV system, should supply the functions for users to scan channels manullay or automatically.
For Q3: Yes, we will review some APIs, on the base of firefox os' existing webAPIs,merge the overlapping part.
For Q4&Q5: This is our following treatment.

Comment 11

[super-zou]

(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #9)
> Hi super-zou,
> 
> Thanks for contributing. Some comments about your patch:
> 
>  - The patch is quite large and thus hard to review. Maybe you can split it
> up into multiple pieces and get each piece reviewed individually. If
> possible, try to get the basic functionally reviewed first, and extras in
> separate patch later.
> 
>  - What are all these empty interfaces for? The comment says its for
> backward compatibility, but I don't expect that empty interfaces would make
> it through a review.
> 
>  - We'd really need some back-end code to make any use of this interface.
> There are Marionette test cases in the patch (they should be reviewed
> separately, btw) and it would be great to have a backend that's generic
> enough to do some testing in our emulator.

Thanks for your suggestion!
We will split the patch into independent pieces and add some brief descriptions and user cases.

Comment 12

[Gene Lian (I already quit Mozilla)]

We have some internal discussion about TVCiManager/TVPictureManager. We think these features can directly be controlled by the Settings API. We don't really need to add new APIs for them. Specifically, for TVCiManager, apps will only read it instead of writing it, because platform will be in charge of the setting. For TVPictureManager, apps will change the settings' value and platform will communicate with the hardware based on the changed value.

Comment 13

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I thought there was a move away from the Settings API? You even started the discussion: https://groups.google.com/forum/#!searchin/mozilla.dev.webapi/settings/mozilla.dev.webapi/Cqbs6bZTK1Y/9C1ckK4qlUMJ

Comment 14

[super-zou]

(In reply to Gene Lian [:gene] (work week Mar. 5 ~ Mar. 7) from comment #12)
> We have some internal discussion about TVCiManager/TVPictureManager. We
> think these features can directly be controlled by the Settings API. We
> don't really need to add new APIs for them. Specifically, for TVCiManager,
> apps will only read it instead of writing it, because platform will be in
> charge of the setting. For TVPictureManager, apps will change the settings'
> value and platform will communicate with the hardware based on the changed
> value.
Hi Gene Lian,
    These APIs we supplied are mainly proprietary for TV device(ATV/DTV)'s Settings menu,
the TV device is more complicated than other device and B2G's existing APIs can not satisfy it. 
For example, TV device needs set  scene,mode and SRS effect of sound, but B2G's sound 
APIs don't have these APIs. TV has multi-input source, like ATV ,DTV, PC,Ypbpr, HDMI and so on,
user possibly switch the source,each source should manage its own settings, but B2G system didn't 
think about it now.

Comment 15

[BMO Automation]

Firefox OS is not being worked on