[Bug 13692] Last call comments on HTML5 from broadcaster's point of view

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13692

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ian@hixie.ch
         Resolution|                            |WONTFIX

--- Comment #1 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-08-22 22:51:40 UTC ---
> ** Use case #1: Broadcaster sends immediate trigger in live program
>  1. A user is watching a live program. (e.g. boxing matches)
>  2. The broadcaster provides sports betting service with browser.
>  3. The match ends suddenly.
>  4. The broadcaster want to close their bet immediately. And they will open
> next bet when next match get started but the start time is not sure.

This is already possible. Just e.g. open a WebSocket to the server and have the
server send a notification over the WebSocket when betting is to open or close.


> ** Use case #2: Broadcaster sends immediate trigger for emergency information
>  1. A user is watching a program. (e.g. drama)
>  2. Big quake happens. Tsunami will arrive in 5 minutes.
>  3. A broadcaster wants to notify users of the tsunami immediately. The
> duration to show the emergency information can't be defined the moment when the
> broadcaster sends the cue.

Emergency notification is the task of an emergency notification tool, not the
video rendering part of HTML. For example, an iPhone user watching a video show
would get the notification via the iPhone earthquake notification subsystem,
not via the Web page of the video show.


> ** Use case #3: HDD recorder sends immediate trigger in recorded live program
>  1. A user records the live boxing program of use case #1 with some kind of HDD
> recorder, it means, the HDD recorder records all tracks related to the program
> including timed text tracks.
>  2. The user watches the program from the HDD recorder after the match
> finished.
>  3. The broadcaster don't want to provide sports betting service for non-live
> viewers (users). So the behavior of the recorded live program must be different
> from that of the original live program.

Just use existing Web mechanisms for enabling and disabling UIs. Nothing to do
with video.


> ** Use case #4: Broadcaster sends immediate trigger after passing a leap second
>  1. Users are watching a live program. (e.g. boxing matches)
>  2. The broadcaster provides sports betting service with browser.
>  3. A leap second passes.
>  4. The match ends suddenly.
>  5. The broadcaster want to close their bet immediately. And they will open
> next bet when next match get started but the start time is not sure.

If you use a WebSocket or other such channel, the leap second is irrelevant.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: This feedback seems predicated on the idea that the video stream is
where things will be happening. This is not how things work on the Web. The
video stream is just where video is to be sent; normal operation such as
sending application updates, earthquake notifications, etc, happen using
generic communication mechanisms, not the video subsystem.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 22 August 2011 22:51:46 UTC