Because the content I watch off of the Internet is mostly the kind you
pay for (i.e., no commercials and hi-def for big screen TVs) - and
that is therefore protected with DRM (movie rentals and TV shows from
iTunes), HTML5 video tag isn't going to change my life much because it
doesn't enable those kind of sites to do DRM to protect their video
content.

I've burnt out on Hulu as its content selection has gotten poorer and
poorer over time. Sure I watch things on YouTube, but now that YouTube
does hi-def, I prefer to watch YouTube via AppleTV anyway (thereby
pumping YouTube content to my big screen TV). Doing the majority of
video viewing from an ipod/iphone/itouch/ipad mobile device is a major
step backwards from watching video content on my big screen TV -
particularly when much of what I watch I want to watch with other
people. Given my Internet viewing habits, the HTML5 video tag is
rather over-hyped.

As a developer, the very favorite thing I see in HTML5, and that has
me most excited, is Sever-Sent Events and bi-directional WebSockets.
And the great thing about these two features is that the Flash Player
will ultimately benefit from them too. So even though we're doing
Comet server-side push now via the BlazeDS servlet from Adobe, HTML5
will be the basis for doing server-side push and/or two-way messaging
in a more efficient manner - and one that is formalized into a real
standard. Nice thing about Server-Sent Events is that is pretty darn
simple and it formalizes HTTP streaming, so we should expect to see
all browsers (and web servers) supporting HTTP streaming explicitly in
order to get HTML5 compliant.

WebSockets looks to be something that Flex code running in Flash
Player will get far more benefit from than HTML/JavaScript in a web
page. Flex is a much better equipped context from which to make use of
such an i/o facility. A future Flash Player release will be able to
adopt it as an improvement to its current socket connection and
messaging support i/o options. WebSockets will provide an HTTP header
protocol to establish and upgrade the connection to a TCP socket
supporting bi-directional messaging of text or binary message frames.
Origin header stamped in by the browser (or Flash Player) can be
leveraged by the server-side to check against a white list, etc., and
fend against cross-site request forgery attacks. Yet looks like will
need to do HTTPS to be sure to pass through web proxies - until web
proxies are upgraded to be fully WebSocket protocol aware.

-- 
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Reply via email to