Re: [webkit-dev] HbbTV support within Webkit

2012-10-13 Thread Graham Mudd
Title: Samsung Enterprise Portal mySingle


I think the objections to this are reasonable andit's probably worth a note on why we proposed this.
The problem with the HbbTV standard is that it's not just a paper spec anymore, it's now widely deployed in several European countries.
Germany is the leading market for HbbTV, but there are many other countries lining up to follow suit.
As a result, there are probably millions of CE devices out there which support HbbTV - and I'm pretty sure it will be tens of millions soon (if it isn't already).
There are also a large number of live apps now, with plenty more in development. I'm not sure if that qualifies as a "wealth of existing content", but it's there.
So for better or worse, as the developers of TV softwarewe have to build HbbTV capability into our stack. And I know we aren't the only CE device maker using WebKit to do this, so we offered up the patches to see if there was any interest in incorporating them.
Now we have a definitive answer, we'll have to find a plan B.
Given your points about the direction of WebKit in general, wewill raise these issueswith thegroup that develops the standard. Maybe there are things that can be made more WebKit friendly in HbbTV 2.0.

Regards
Graham


--- Original Message ---
Sender : Randall Bennettrandall.benn...@gmail.com
Date : Oct 12, 2012 21:20 (GMT+01:00)
Title : Re: [webkit-dev] HbbTV support within Webkit

On Thu, Oct 11, 2012 at 12:16 PM, Maciej Stachowiak m...@apple.com wrote: 

On Oct 11, 2012, at 7:40 AM, Mark Toller mark.tol...@samsung.com wrote:  -Original Message-  From: Dominik Röttsches [mailto:dominik.rottsc...@intel.com]   On 10/10/2012 10:26 AM, Mark Toller wrote:  What we would like to see initially is Webkit based browsers (Chrome,  Safari, Minibrowser, etc) actually load HbbTV pages instead of asking  the user to download the content - this would indirectly benefit the  end goal of Webkit (to get everyone to support standard W3C/HTML5)...   This particular change is just a matter of adding one more displayable  mime-type, right?   Almost. I've created a bug and patch for this particular change:   https://bugs.webkit.org/show_bug.cgi?id=99049   As someone else stated, I think the best approach is to create  a bug for each change we consider worthwhile, and then they can be  considered individually. I don't think we should take this change or accept this feature in general. It seems that of those who have spoken up, the WebKit community is not in favor of this direction. 


Even though the specific change in that patch is relatively small, supporting custom MIME types has significant disadvantages: - Creates interoperability issues with other browsers. - Fragments the web - Opens us up to further requests to add support for similarly niche MIME types in the future If CE-HTML and HbbTV content is fine to process as ordinary HTML, then it should be served with text/html MIME type. That would avoid all of these problems. If a consortium decided to create custom mime types instead, then they made a mistake and should fix it. In some cases, when the technology is compelling or there is a wealth of existing content, we live with arguable errors in the standard. But neither of those considerations applies here. Regards, Maciej 

___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev 


+1. As someone who builds applications specifically for TV producers, I feel that this custom mime type is the first in a series of bad moves.

Why doesn't the HBB group form its own W3 style group? I think this is just heading in the wrong direction.

rb



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HbbTV support within Webkit

2012-10-13 Thread Adam Barth
A good start would be a freely available, free to implement, open standard.

Adam
 On Oct 13, 2012 7:19 PM, Graham Mudd graham.m...@samsung.com wrote:

  I think the objections to this are reasonable and it's probably worth a
 note on why we proposed this.

 The problem with the HbbTV standard is that it's not just a paper spec
 anymore, it's now widely deployed in several European countries.

 Germany is the leading market for HbbTV, but there are many other
 countries lining up to follow suit.

 As a result, there are probably millions of CE devices out there which
 support HbbTV - and I'm pretty sure it will be tens of millions soon (if it
 isn't already).

 There are also a large number of live apps now, with plenty more in
 development. I'm not sure if that qualifies as a wealth of existing
 content, but it's there.

 So for better or worse, as the developers of TV software we have to build
 HbbTV capability into our stack. And I know we aren't the only CE device
 maker using WebKit to do this, so we offered up the patches to see if there
 was any interest in incorporating them.

 Now we have a definitive answer, we'll have to find a plan B.

 Given your points about the direction of WebKit in general, we will raise
 these issues with the group that develops the standard. Maybe there are
 things that can be made more WebKit friendly in HbbTV 2.0.



 Regards

 Graham





 --- *Original Message* ---

 *Sender* : Randall Bennettrandall.benn...@gmail.com

 *Date* : Oct 12, 2012 21:20 (GMT+01:00)

 *Title* : Re: [webkit-dev] HbbTV support within Webkit




 On Thu, Oct 11, 2012 at 12:16 PM, Maciej Stachowiak m...@apple.comwrote:


 On Oct 11, 2012, at 7:40 AM, Mark Toller mark.tol...@samsung.com
 wrote:

  -Original Message-
  From: Dominik Röttsches [mailto:dominik.rottsc...@intel.com]
 
  On 10/10/2012 10:26 AM, Mark Toller wrote:
  What we would like to see initially is Webkit based browsers (Chrome,
  Safari, Minibrowser, etc) actually load HbbTV pages instead of asking
  the user to download the content - this would indirectly benefit the
  end goal of Webkit (to get everyone to support standard W3C/HTML5)...
 
  This particular change is just a matter of adding one more displayable
  mime-type, right?
 
  Almost. I've created a bug and patch for this particular change:
 
  https://bugs.webkit.org/show_bug.cgi?id=99049
 
  As someone else stated, I think the best approach is to create
  a bug for each change we consider worthwhile, and then they can be
  considered individually.

 I don't think we should take this change or accept this feature in
 general. It seems that of those who have spoken up, the WebKit community is
 not in favor of this direction.



 Even though the specific change in that patch is relatively small,
 supporting custom MIME types has significant disadvantages:

 - Creates interoperability issues with other browsers.
 - Fragments the web
 - Opens us up to further requests to add support for similarly niche MIME
 types in the future

 If CE-HTML and HbbTV content is fine to process as ordinary HTML, then it
 should be served with text/html MIME type. That would avoid all of these
 problems. If a consortium decided to create custom mime types instead, then
 they made a mistake and should fix it. In some cases, when the technology
 is compelling or there is a wealth of existing content, we live with
 arguable errors in the standard. But neither of those considerations
 applies here.

 Regards,
 Maciej

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



  +1. As someone who builds applications specifically for TV producers, I
 feel that this custom mime type is the first in a series of bad moves.

 Why doesn't the HBB group form its own W3 style group? I think this is
 just heading in the wrong direction.

 rb







 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HbbTV support within Webkit

2012-10-12 Thread Randall Bennett
On Thu, Oct 11, 2012 at 12:16 PM, Maciej Stachowiak m...@apple.com wrote:


 On Oct 11, 2012, at 7:40 AM, Mark Toller mark.tol...@samsung.com wrote:

  -Original Message-
  From: Dominik Röttsches [mailto:dominik.rottsc...@intel.com]
 
  On 10/10/2012 10:26 AM, Mark Toller wrote:
  What we would like to see initially is Webkit based browsers (Chrome,
  Safari, Minibrowser, etc) actually load HbbTV pages instead of asking
  the user to download the content - this would indirectly benefit the
  end goal of Webkit (to get everyone to support standard W3C/HTML5)...
 
  This particular change is just a matter of adding one more displayable
  mime-type, right?
 
  Almost. I've created a bug and patch for this particular change:
 
  https://bugs.webkit.org/show_bug.cgi?id=99049
 
  As someone else stated, I think the best approach is to create
  a bug for each change we consider worthwhile, and then they can be
  considered individually.

 I don't think we should take this change or accept this feature in
 general. It seems that of those who have spoken up, the WebKit community is
 not in favor of this direction.



 Even though the specific change in that patch is relatively small,
 supporting custom MIME types has significant disadvantages:

 - Creates interoperability issues with other browsers.
 - Fragments the web
 - Opens us up to further requests to add support for similarly niche MIME
 types in the future

 If CE-HTML and HbbTV content is fine to process as ordinary HTML, then it
 should be served with text/html MIME type. That would avoid all of these
 problems. If a consortium decided to create custom mime types instead, then
 they made a mistake and should fix it. In some cases, when the technology
 is compelling or there is a wealth of existing content, we live with
 arguable errors in the standard. But neither of those considerations
 applies here.

 Regards,
 Maciej

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



 +1. As someone who builds applications specifically for TV producers, I
feel that this custom mime type is the first in a series of bad moves.

Why doesn't the HBB group form its own W3 style group? I think this is just
heading in the wrong direction.

rb
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HbbTV support within Webkit

2012-10-11 Thread Dominik Röttsches

On 10/10/2012 10:26 AM, Mark Toller wrote:

What we would like to see initially is Webkit based browsers (Chrome,
Safari, Minibrowser, etc) actually load HbbTV pages instead of asking the
user to download the content - this would indirectly benefit the end goal of
Webkit (to get everyone to support standard W3C/HTML5)...
This particular change is just a matter of adding one more displayable 
mime-type, right?


Dominik

--
Dominik Röttsches dominik.rottsc...@intel.com

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HbbTV support within Webkit

2012-10-11 Thread Mark Toller
 -Original Message-
 From: Dominik Röttsches [mailto:dominik.rottsc...@intel.com]

 On 10/10/2012 10:26 AM, Mark Toller wrote:
  What we would like to see initially is Webkit based browsers (Chrome,
  Safari, Minibrowser, etc) actually load HbbTV pages instead of asking
  the user to download the content - this would indirectly benefit the 
  end goal of Webkit (to get everyone to support standard W3C/HTML5)...

 This particular change is just a matter of adding one more displayable
 mime-type, right?

Almost. I've created a bug and patch for this particular change:

https://bugs.webkit.org/show_bug.cgi?id=99049

As someone else stated, I think the best approach is to create
a bug for each change we consider worthwhile, and then they can be 
considered individually.

Regards,

Mark.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HbbTV support within Webkit

2012-10-10 Thread Mark Toller
Hi,

HbbTV and OIPF specifications are available to download from the HbbTV and
OIPF sites:

http://www.hbbtv.org/pages/about_hbbtv/specification.php
http://www.oipf.tv/specifications

The closed standard is the CE-HTML standard, which is referenced by OIPF.
The portions of CE-HTML used by HbbTV and OIPF are essentially a profile of
W3C standards and the AV Control plugin.

We're currently looking at our changes to identify areas that can be
delivered back which can provide benefit to Webkit without causing any
additional maintenance overhead. 

What we would like to see initially is Webkit based browsers (Chrome,
Safari, Minibrowser, etc) actually load HbbTV pages instead of asking the
user to download the content - this would indirectly benefit the end goal of
Webkit (to get everyone to support standard W3C/HTML5)... As you can
imagine, most application authors are web developers, and do not necessarily
have experience with HbbTV, OIPF or CE-HTML, so they use the standard
W3C/HTML5/XHTML constructs they are familiar with, except for the TV
specific API's or plugins. More often than not, they'll write their
application so that it can also run on a PC browser, because they have far
better debugging facilities than TVs! However, as soon as the application is
signalled correctly with an HbbTV or CE-HTML mime type, most browsers then
just ask to download the page. Also, many test with a browser in 'HTML'
mode, and not the stricter 'XHTML' mode.

Regards,

Mark.

-Original Message-
From: aba...@gmail.com [mailto:aba...@gmail.com] On Behalf Of Adam Barth
Sent: 08 October 2012 19:36
To: Mark Toller
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] HbbTV support within Webkit

From your message, it sounds like HbbTV is still not an open standard.
 I'm skeptical that we should support closed standards in WebKit.

Adam


On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller mark.tol...@samsung.com wrote:
 Hi,



 I'd like to ask the Webkit developers their opinion on providing some
 support for HbbTV [1] within Webkit. Hybrid Broadcast Broadband TV or
 HbbTV, is a major new pan-European initiative aimed at harmonising the
 broadcast and broadband delivery of entertainment to the end consumer
 through connected TVs and set-top boxes.  The HbbTV standard is proving to
 be very popular, TVs and STBs supporting HbbTV are shipping in huge
numbers
 throughout Europe.  HbbTV is built on top of OIPF [2], which in turn is
 based on portions of CE-HTML [3].



 Our lab, Samsung Electronics Research Institute (SERI), has been heavily
 involved in HbbTV and our current solution is based on Webkit. We would
like
 to provide our changes back to the community.



 I know that support requests for CE-HTML have been briefly touched upon in
 the past. As I understand it, the main objection to providing support
within
 WebKit is that the CE-HTML specification is not freely available, and thus
 restricts the number of developers who can fully understand it and
therefore
 provide fixes / support.



 In reality, much of the CE-HTML specification simply profiles which parts
of
 the W3C standard behaviour are mandatory, optional and/or recommended.
OIPF
 then profiles CE-HTML (dropping some requirements, extending others to
match
 W3C/HTML5), HbbTV profiles out even more of CE-HTML.



 Other parts of OIPF and CE-HTML do not need to be implemented within
Webkit
 itself. Some can be implemented as object plugins (e.g. AV Control and
local
 video), while others, such as the JavaScript classes required, can be
 inserted into the JavaScriptCore at runtime.



 What I propose is to provide the basic support required within Webkit in
 order to at least load the XHTML portions of HbbTV applications and
provide
 the correct key handling to drive them. In order to provide 'full' HbbTV
 support, implementations would need to provide the plugins and additional
 JavaScript classes to complete the picture.



 For instance, by simply adding support for the document mime type handling
 of application/vnd.hbbtv.xhtml+xml and application/ce-html+xml, many HbbTV
 applications will load and display the main page, and several will also
 correctly navigate around the application correctly.



 Regards,



 Mark.



 [1] Hybrid Broadcast Broadband TV - http://www.hbbtv.org/

 [2] Open IPTV Forum - http://www.oipf.tv/

 [3] CEA, CEA-2014-A, Web-based Protocol Framework for Remote User
Interface
 on UPnP Networks and the Internet (Web4CE)






 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HbbTV support within Webkit

2012-10-10 Thread Kenneth Rohde Christiansen
Hi,

I still don't get it. CE-HTML is a closed standard and not something
we ever want in WebKit as we are pushing HTML5/Living Standard.

I understand that you need some execution and security model, but
apart from that I don't see why you don't aim at supporting HTML5
instead of some custom dialect that is moving in another direction
that they rest of the industry. Even with the System Applications
working group [1], which Samsung is co-chairing, the execution and
security model will get solved with proper participation.

Also the need for using XHTML isn't that big anymore, now that HTML5
defines how to actually parse the document.

Cheers
Kenneth

[1] http://www.w3.org/2012/05/sysapps-wg-charter.html



On Wed, Oct 10, 2012 at 9:26 AM, Mark Toller mark.tol...@samsung.com wrote:
 Hi,

 HbbTV and OIPF specifications are available to download from the HbbTV and
 OIPF sites:

 http://www.hbbtv.org/pages/about_hbbtv/specification.php
 http://www.oipf.tv/specifications

 The closed standard is the CE-HTML standard, which is referenced by OIPF.
 The portions of CE-HTML used by HbbTV and OIPF are essentially a profile of
 W3C standards and the AV Control plugin.

 We're currently looking at our changes to identify areas that can be
 delivered back which can provide benefit to Webkit without causing any
 additional maintenance overhead.

 What we would like to see initially is Webkit based browsers (Chrome,
 Safari, Minibrowser, etc) actually load HbbTV pages instead of asking the
 user to download the content - this would indirectly benefit the end goal of
 Webkit (to get everyone to support standard W3C/HTML5)... As you can
 imagine, most application authors are web developers, and do not necessarily
 have experience with HbbTV, OIPF or CE-HTML, so they use the standard
 W3C/HTML5/XHTML constructs they are familiar with, except for the TV
 specific API's or plugins. More often than not, they'll write their
 application so that it can also run on a PC browser, because they have far
 better debugging facilities than TVs! However, as soon as the application is
 signalled correctly with an HbbTV or CE-HTML mime type, most browsers then
 just ask to download the page. Also, many test with a browser in 'HTML'
 mode, and not the stricter 'XHTML' mode.

 Regards,

 Mark.

 -Original Message-
 From: aba...@gmail.com [mailto:aba...@gmail.com] On Behalf Of Adam Barth
 Sent: 08 October 2012 19:36
 To: Mark Toller
 Cc: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] HbbTV support within Webkit

 From your message, it sounds like HbbTV is still not an open standard.
  I'm skeptical that we should support closed standards in WebKit.

 Adam


 On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller mark.tol...@samsung.com wrote:
 Hi,



 I'd like to ask the Webkit developers their opinion on providing some
 support for HbbTV [1] within Webkit. Hybrid Broadcast Broadband TV or
 HbbTV, is a major new pan-European initiative aimed at harmonising the
 broadcast and broadband delivery of entertainment to the end consumer
 through connected TVs and set-top boxes.  The HbbTV standard is proving to
 be very popular, TVs and STBs supporting HbbTV are shipping in huge
 numbers
 throughout Europe.  HbbTV is built on top of OIPF [2], which in turn is
 based on portions of CE-HTML [3].



 Our lab, Samsung Electronics Research Institute (SERI), has been heavily
 involved in HbbTV and our current solution is based on Webkit. We would
 like
 to provide our changes back to the community.



 I know that support requests for CE-HTML have been briefly touched upon in
 the past. As I understand it, the main objection to providing support
 within
 WebKit is that the CE-HTML specification is not freely available, and thus
 restricts the number of developers who can fully understand it and
 therefore
 provide fixes / support.



 In reality, much of the CE-HTML specification simply profiles which parts
 of
 the W3C standard behaviour are mandatory, optional and/or recommended.
 OIPF
 then profiles CE-HTML (dropping some requirements, extending others to
 match
 W3C/HTML5), HbbTV profiles out even more of CE-HTML.



 Other parts of OIPF and CE-HTML do not need to be implemented within
 Webkit
 itself. Some can be implemented as object plugins (e.g. AV Control and
 local
 video), while others, such as the JavaScript classes required, can be
 inserted into the JavaScriptCore at runtime.



 What I propose is to provide the basic support required within Webkit in
 order to at least load the XHTML portions of HbbTV applications and
 provide
 the correct key handling to drive them. In order to provide 'full' HbbTV
 support, implementations would need to provide the plugins and additional
 JavaScript classes to complete the picture.



 For instance, by simply adding support for the document mime type handling
 of application/vnd.hbbtv.xhtml+xml and application/ce-html+xml, many HbbTV
 applications will load and display the main page, and several

Re: [webkit-dev] HbbTV support within Webkit

2012-10-10 Thread Glenn Adams
On Wed, Oct 10, 2012 at 3:50 PM, Kenneth Rohde Christiansen 
kenneth.christian...@gmail.com wrote:

 Hi,

 I still don't get it. CE-HTML is a closed standard and not something
 we ever want in WebKit as we are pushing HTML5/Living Standard.


Just to provide some additional input. CE-HMTL, more formally known as
CEA-2014, is *not* a closed standard. It is available to anyone who wishes
to pay CEA for a copy. In that respect, it is no different from ISO/ITU
standards that sometimes cost money to obtain a copy.



 I understand that you need some execution and security model, but
 apart from that I don't see why you don't aim at supporting HTML5
 instead of some custom dialect that is moving in another direction
 that they rest of the industry. Even with the System Applications
 working group [1], which Samsung is co-chairing, the execution and
 security model will get solved with proper participation.

 Also the need for using XHTML isn't that big anymore, now that HTML5
 defines how to actually parse the document.


Rather than delving deeper into this proposal, I would suggest the original
commenter should make some very specific technical proposals (accompanied
by actual patches) that may satisfy his requirements, instead of simply
propose support for the higher level notion of this profile. The merit of
such individual technical proposals (patches) can be evaluated on a case by
case basis, as is the case with other features proposed for addition to WK.

Regards, Glenn
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] HbbTV support within Webkit

2012-10-08 Thread Mark Toller
Hi,

I'd like to ask the Webkit developers their opinion on providing some support 
for HbbTV [1] within Webkit. Hybrid Broadcast Broadband TV or HbbTV, is a 
major new pan-European initiative aimed at harmonising the broadcast and 
broadband delivery of entertainment to the end consumer through connected TVs 
and set-top boxes.  The HbbTV standard is proving to be very popular, TVs and 
STBs supporting HbbTV are shipping in huge numbers throughout Europe.  HbbTV is 
built on top of OIPF [2], which in turn is based on portions of CE-HTML [3].

Our lab, Samsung Electronics Research Institute (SERI), has been heavily 
involved in HbbTV and our current solution is based on Webkit. We would like to 
provide our changes back to the community.

I know that support requests for CE-HTML have been briefly touched upon in the 
past. As I understand it, the main objection to providing support within WebKit 
is that the CE-HTML specification is not freely available, and thus restricts 
the number of developers who can fully understand it and therefore provide 
fixes / support.

In reality, much of the CE-HTML specification simply profiles which parts of 
the W3C standard behaviour are mandatory, optional and/or recommended. OIPF 
then profiles CE-HTML (dropping some requirements, extending others to match 
W3C/HTML5), HbbTV profiles out even more of CE-HTML.

Other parts of OIPF and CE-HTML do not need to be implemented within Webkit 
itself. Some can be implemented as object plugins (e.g. AV Control and local 
video), while others, such as the JavaScript classes required, can be inserted 
into the JavaScriptCore at runtime.

What I propose is to provide the basic support required within Webkit in order 
to at least load the XHTML portions of HbbTV applications and provide the 
correct key handling to drive them. In order to provide 'full' HbbTV support, 
implementations would need to provide the plugins and additional JavaScript 
classes to complete the picture.

For instance, by simply adding support for the document mime type handling of 
application/vnd.hbbtv.xhtml+xml and application/ce-html+xml, many HbbTV 
applications will load and display the main page, and several will also 
correctly navigate around the application correctly.

Regards,

Mark.

[1] Hybrid Broadcast Broadband TV - http://www.hbbtv.org/
[2] Open IPTV Forum - http://www.oipf.tv/
[3] CEA, CEA-2014-A, Web-based Protocol Framework for Remote User Interface on 
UPnP Networks and the Internet (Web4CE)


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HbbTV support within Webkit

2012-10-08 Thread Martin Robinson
On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller mark.tol...@samsung.com wrote:
 I know that support requests for CE-HTML have been briefly touched upon in
 the past. As I understand it, the main objection to providing support within
 WebKit is that the CE-HTML specification is not freely available, and thus
 restricts the number of developers who can fully understand it and therefore
 provide fixes / support.

For reference, here is a link to the previous thread:
https://lists.webkit.org/pipermail/webkit-dev/2011-June/017195.html

--Martin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HbbTV support within Webkit

2012-10-08 Thread Ryosuke Niwa
On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller mark.tol...@samsung.comwrote:

 **

 I'd like to ask the Webkit developers their opinion on providing some
 support for HbbTV [1] within Webkit.


By some support, what exactly do you mean?

Our lab, Samsung Electronics Research Institute (SERI), has been heavily
 involved in HbbTV and our current solution is based on Webkit. We would
 like to provide our changes back to the community.

 I know that support requests for CE-HTML have been briefly touched upon in
 the past. As I understand it, the main objection to providing support
 within WebKit is that the CE-HTML specification is not freely available,
 and thus restricts the number of developers who can fully understand it and
 therefore provide fixes / support.

 **


It also burdens other contributors who refactor and maintain that code. WML
was a mess and imposed a significant maintenance cost on everyone who
worked on script and input elements.

In reality, much of the CE-HTML specification simply profiles which parts
 of the W3C standard behaviour are mandatory, optional and/or recommended.
 OIPF then profiles CE-HTML (dropping some requirements, extending others to
 match W3C/HTML5), HbbTV profiles out even more of CE-HTML. 

 ** **

 Other parts of OIPF and CE-HTML do not need to be implemented within
 Webkit itself. Some can be implemented as object plugins (e.g. AV Control
 and local video), while others, such as the JavaScript classes required,
 can be inserted into the JavaScriptCore at runtime.


I have a hard time understanding the exact requirement for supporting
CE-HTML and HbbTV. What kind of changes do you want to make to the trunk
WebKit?

What I propose is to provide the basic support required within Webkit in
 order to at least load the XHTML portions of HbbTV applications and provide
 the correct key handling to drive them. In order to provide 'full' HbbTV
 support, implementations would need to provide the plugins and additional
 JavaScript classes to complete the picture.


Making WebKit more pluggable to support CE-HTML and HbbTV sound good to me
as long as it doesn't significantly increase the maintenance burden on
contributors.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HbbTV support within Webkit

2012-10-08 Thread Adam Barth
From your message, it sounds like HbbTV is still not an open standard.
 I'm skeptical that we should support closed standards in WebKit.

Adam


On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller mark.tol...@samsung.com wrote:
 Hi,



 I'd like to ask the Webkit developers their opinion on providing some
 support for HbbTV [1] within Webkit. Hybrid Broadcast Broadband TV or
 HbbTV, is a major new pan-European initiative aimed at harmonising the
 broadcast and broadband delivery of entertainment to the end consumer
 through connected TVs and set-top boxes.  The HbbTV standard is proving to
 be very popular, TVs and STBs supporting HbbTV are shipping in huge numbers
 throughout Europe.  HbbTV is built on top of OIPF [2], which in turn is
 based on portions of CE-HTML [3].



 Our lab, Samsung Electronics Research Institute (SERI), has been heavily
 involved in HbbTV and our current solution is based on Webkit. We would like
 to provide our changes back to the community.



 I know that support requests for CE-HTML have been briefly touched upon in
 the past. As I understand it, the main objection to providing support within
 WebKit is that the CE-HTML specification is not freely available, and thus
 restricts the number of developers who can fully understand it and therefore
 provide fixes / support.



 In reality, much of the CE-HTML specification simply profiles which parts of
 the W3C standard behaviour are mandatory, optional and/or recommended. OIPF
 then profiles CE-HTML (dropping some requirements, extending others to match
 W3C/HTML5), HbbTV profiles out even more of CE-HTML.



 Other parts of OIPF and CE-HTML do not need to be implemented within Webkit
 itself. Some can be implemented as object plugins (e.g. AV Control and local
 video), while others, such as the JavaScript classes required, can be
 inserted into the JavaScriptCore at runtime.



 What I propose is to provide the basic support required within Webkit in
 order to at least load the XHTML portions of HbbTV applications and provide
 the correct key handling to drive them. In order to provide 'full' HbbTV
 support, implementations would need to provide the plugins and additional
 JavaScript classes to complete the picture.



 For instance, by simply adding support for the document mime type handling
 of application/vnd.hbbtv.xhtml+xml and application/ce-html+xml, many HbbTV
 applications will load and display the main page, and several will also
 correctly navigate around the application correctly.



 Regards,



 Mark.



 [1] Hybrid Broadcast Broadband TV - http://www.hbbtv.org/

 [2] Open IPTV Forum - http://www.oipf.tv/

 [3] CEA, CEA-2014-A, Web-based Protocol Framework for Remote User Interface
 on UPnP Networks and the Internet (Web4CE)






 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HbbTV support within Webkit

2012-10-08 Thread Maciej Stachowiak

Adding support for custom variants of HTML is not really in line with the goals 
of the WebKit project. It sounds like CE-HTML and OIPF are both HTML variants. 
I don't think these types of features are a good fit for WebKit, because:

(1) Custom HTML dialects tend to create excessive maintenance burden for the 
contributors who are not interested in the feature. WAP is a historical 
example. We much prefer features that either have broad mainstream interest, or 
at the very least can be implemented with minimal intrusion into core code.

(2) Most contributors to the WebKit project strongly believe in a One Web 
vision, where the same full core specifications are used in all the contexts 
where Web technology is useful - no special dialects for mobile, or tv, or 
whatever, it's all one web. Custom HTML dialects go against that vision, so the 
value of adding support would have to be very high to even consider it.

I strongly recommend that the HbbTV effort should use HTML5 and other Web 
technologies directly, rather than profiling and extending the Web.

Regards,
Maciej

On Oct 8, 2012, at 7:11 AM, Mark Toller mark.tol...@samsung.com wrote:

 Hi,
  
 I'd like to ask the Webkit developers their opinion on providing some support 
 for HbbTV [1] within Webkit. Hybrid Broadcast Broadband TV or HbbTV, is a 
 major new pan-European initiative aimed at harmonising the broadcast and 
 broadband delivery of entertainment to the end consumer through connected TVs 
 and set-top boxes.  The HbbTV standard is proving to be very popular, TVs and 
 STBs supporting HbbTV are shipping in huge numbers throughout Europe.  HbbTV 
 is built on top of OIPF [2], which in turn is based on portions of CE-HTML 
 [3].
  
 Our lab, Samsung Electronics Research Institute (SERI), has been heavily 
 involved in HbbTV and our current solution is based on Webkit. We would like 
 to provide our changes back to the community.
  
 I know that support requests for CE-HTML have been briefly touched upon in 
 the past. As I understand it, the main objection to providing support within 
 WebKit is that the CE-HTML specification is not freely available, and thus 
 restricts the number of developers who can fully understand it and therefore 
 provide fixes / support.
  
 In reality, much of the CE-HTML specification simply profiles which parts of 
 the W3C standard behaviour are mandatory, optional and/or recommended. OIPF 
 then profiles CE-HTML (dropping some requirements, extending others to match 
 W3C/HTML5), HbbTV profiles out even more of CE-HTML.
  
 Other parts of OIPF and CE-HTML do not need to be implemented within Webkit 
 itself. Some can be implemented as object plugins (e.g. AV Control and local 
 video), while others, such as the JavaScript classes required, can be 
 inserted into the JavaScriptCore at runtime.
  
 What I propose is to provide the basic support required within Webkit in 
 order to at least load the XHTML portions of HbbTV applications and provide 
 the correct key handling to drive them. In order to provide 'full' HbbTV 
 support, implementations would need to provide the plugins and additional 
 JavaScript classes to complete the picture.
  
 For instance, by simply adding support for the document mime type handling of 
 application/vnd.hbbtv.xhtml+xml and application/ce-html+xml, many HbbTV 
 applications will load and display the main page, and several will also 
 correctly navigate around the application correctly.
  
 Regards,
  
 Mark.
  
 [1] Hybrid Broadcast Broadband TV - http://www.hbbtv.org/
 [2] Open IPTV Forum - http://www.oipf.tv/
 [3] CEA, CEA-2014-A, Web-based Protocol Framework for Remote User Interface 
 on UPnP Networks and the Internet (Web4CE)
  
  
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev