W3C home > Mailing lists > Public > public-web-and-tv@w3.org > August 2011

RE: [HOME_NETWORK_TF] Some comments on Home Network Enabled User-Agent use cases

From: Russell Berkoff <r.berkoff@sisa.samsung.com>
Date: Tue, 16 Aug 2011 00:26:04 -0700
Message-ID: <C13F012EB82CF34F857044FC755E3552B98CE9@hermes.sisa.samsung.com>
To: "Giuseppe Pascale" <giuseppep@opera.com>, "Web and TV Interest Group WG" <public-web-and-tv@w3.org>
Hello,

 

Please see in-line comments.


Regards,

Russell Berkoff

 

From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-request@w3.org] On Behalf Of Giuseppe Pascale
Sent: Monday, August 15, 2011 6:32 AM
To: public-web-and-tv@w3.org
Subject: [HOME_NETWORK_TF] Some comments on Home Network Enabled User-Agent use cases

 

forgot to label, sorry

------- Forwarded message -------
From: "Giuseppe Pascale" <giuseppep@opera.com>
To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Cc:
Subject: Some comments on Home Network Enabled User-Agent use cases
Date: Mon, 15 Aug 2011 12:52:23 +0200

Russell, all,
I'm going through the approved use cases once again and I have some additional comments. Sorry for not raising them before.

My comments are around some text, common to several ISSUEs (ISSUE-26, ISSUE-27,ISSUE-28, ISSUE-29).

#1 "Provide extensions to HTML5 <video>, <audio> elements to allow HTML5 to comply with Home Network Media Transport Requirements (mainly transport protocol specific headers)"

 

I think the expression "Home Network Media Transport Requirements" is pretty vague and also the term "provide extensions" seems misleading. Maybe this part could be rephrased with something like "Provide a mean to support additional transport specific headers"

[Russell Berkoff] 

This will probably need some work. This phrase includes requirements for a number of  header-mediated transport behaviors:

1.       The header contains a “command” for the server. For example the header tells the server to serve-up the content at 2x normal rate, or the header tells the server to position the content at 1:00:00.

2.       The header contains information for the web-page. The header indicates the available speeds that the server can serve the content at. Or the header indicates alternate language tracks for the content.

3.       The header contains information for the client’s user-agent playback engine. The header contains information about the content profile (beyond simple mime-types) so the playback function can correctly parse the content stream.

 

Many of these headers are already in use in deployed products.

 

#2 "Also, provide backward-compatible extensions to previous HTML versions to support similar functionality (presumably as browser-plugins)."

I think this is out of scope and should be removed. This is a product problem not a specification problem.

[Russell Berkoff] 

We should  try to provide backward compatibility if possible. At the minimum we should be cognizant that HTML5 content will be consumed by earlier systems. If web-pages can adapt to this then all the better. 

 

#3 "Allow pages to control future Home Network device classes where the comand sets are not currently known."

I think this should be removed as well. I cannot see how we could extract requirement or define a specification to comply with future and unknown requirements. Of course having a flexible architecture that is future proof is a good design goal (and I can add it as such to the requirement document) but I don't think it can be a requirement.

[Russell Berkoff] 

Others do this. The UPnP core model (UDA) is based around some basic services for discovery, network variables, and eventing. The model has proven quite robust and extensible allowing it to support a wide variety of current and future devices without substantial modification. For example:  the difference between HTML <object> and <video> elements. The <object> element allows a lot of things including non-video plugins allowing all sorts of user-agent extensions.  The <video> element only knows about video. Now the <video> element is under “pressure” to support a bunch of additional behaviors. The requirement is to insure the facilities we include are generic and robust enough address future requirements. ISSUE-30 includes some potential future usages.

 

cheers,

/g

 

 

 

 

 









-- 

Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden





-- 

Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Tuesday, 16 August 2011 07:26:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:07 UTC