Roku Developer Program

[rjbrown]

So Roku is going to support DIAL, like Chromecast. Which is awesome, I think.

http://news.cnet.com/8301-1023_3-576025 ... e-feature/

How will this affect Brightscript developers? Will Brightscript still be necessary to build a DIAL app, or will it be all HTML5/Javascript on the Roku device? (with Objective C or Java on the phone/tablet, of course)

[TheEndless]

"rjbrown" wrote:
So Roku is going to support DIAL, like Chromecast. Which is awesome, I think.

http://news.cnet.com/8301-1023_3-576025 ... e-feature/

How will this affect Brightscript developers? Will Brightscript still be necessary to build a DIAL app, or will it be all HTML5/Javascript on the Roku device? (with Objective C or Java on the phone/tablet, of course)

I don't see how this would affect BrightScript developers at all. It's just a new protocol that developers can access from their applications on other devices, and if it's like Chromecast, as the article suggests, then there is no UI on the Roku directly, so HTML5 and Javascript support don't come into play. The third party application running on your mobile device basically just tells the Roku what URL to stream (and presumably what DRM to use). While such a mechanism would certainly have its benefits and uses, I personally don't think it'll ever replace the ability to browse and access the content directly on the Roku (instead of your smart phone or tablet).

[malloys]

"TheEndless" wrote:

"rjbrown" wrote:
So Roku is going to support DIAL, like Chromecast. Which is awesome, I think.

http://news.cnet.com/8301-1023_3-576025 ... e-feature/

How will this affect Brightscript developers? Will Brightscript still be necessary to build a DIAL app, or will it be all HTML5/Javascript on the Roku device? (with Objective C or Java on the phone/tablet, of course)

I don't see how this would affect BrightScript developers at all. It's just a new protocol that developers can access from their applications on other devices, and if it's like Chromecast, as the article suggests, then there is no UI on the Roku directly, so HTML5 and Javascript support don't come into play. The third party application running on your mobile device basically just tells the Roku what URL to stream (and presumably what DRM to use). While such a mechanism would certainly have its benefits and uses, I personally don't think it'll ever replace the ability to browse and access the content directly on the Roku (instead of your smart phone or tablet).

If I'm reading it correctly, the current DIAL protocol spec ( https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGlhbC1tdWx0aXNjcmVlbi5vcmd8ZGlhbHxneDo1NTA2NDQ5M... ) at least in part looks and sounds quite a bit like Roku's existing protocols for discovery and control (SSDP discovery + ECP launch and query/apps commands: http://sdkdocs.roku.com/display/sdkdoc/External+Control+Guide ). The changes necessary to support DIAL on the server (Roku box) side appear to be minimal, but wouldn't add much new functionality for Roku devs.

Hopefully the DIAL protocol will eventually expand to include more detailed info on/from running apps (i.e. channels in our case) about the currently running content meta-data - such as title, description, date, length, current index, etc... - then second-screen applications (DIAL clients) will really have something interesting to work with.

[rjbrown]

"TheEndless" wrote:
and if it's like Chromecast, as the article suggests, then there is no UI on the Roku directly, so HTML5 and Javascript support don't come into play.

Actually, Chromecast does require you to write html5 and javascript that runs on the device. 90% of development happens on the iOS / Android side (the "sender" app), but you still have to write a "receiver" app that runs on the device (it's not installed per se, it is pulled down from a web url that has to be whitelisted by google), and it can do basic stuff like show a progress bar and show various other "read only" things on screen beyond the video itself.

I imagine the receiver app could be written in Brightscript, in theory anyway, although I don't know if that would actually be DIAL. And since such apps are not installed on the device in the usual way, the Brightscript code could be pulled over the net when needed. Or something.

Otherwise, the Roku is going to have to have a minimal browser on it.

I'm aware from another thread that you don't think the Chromecast approach is preferable (i.e. having the apps installed on the smartphone / tablet). I'm curious....do you mostly work on Roku's or do you do any other Smart TV platforms? Because from my perspective --- having to develop similar-but-different video player apps for Roku, Samsung TVs and blue ray players, Opera TV platform, Google TV, Western Digital devices, LG tv's and blue ray players, Vizio, iPad, and more (luckily I haven't had to personally deal with Playstation, Xbox, Yahoo TV platform or Apple TV yet) ---- the current way is a nightmare for developers. (and as a user, I prefer using my phone as a remote)

[TheEndless]

"rjbrown" wrote:
I'm aware from another thread that you don't think the Chromecast approach is preferable (i.e. having the apps installed on the smartphone / tablet). I'm curious....do you mostly work on Roku's or do you do any other Smart TV platforms? Because from my perspective --- having to develop similar-but-different video player apps for Roku, Samsung TVs and blue ray players, Opera TV platform, Google TV, Western Digital devices, LG tv's and blue ray players, Vizio, iPad, and more (luckily I haven't had to personally deal with Playstation, Xbox, Yahoo TV platform or Apple TV yet) ---- the current way is a nightmare for developers. (and as a user, I prefer using my phone as a remote)

I primarily develop for Roku, but my comments and opinions about Chromecast are from an end-user perspective, not a developer perspective. I really don't like the idea of having to look at the remote in order to use it. I also primarily watch TV with other people in my house, so choosing the content we want to watch is much easier if we can all see it on the television, rather than having to crowd around a handheld device. Like I've said before, I can see the benefits of having it as an option, but as a primary interface to the device, it just doesn't make much sense to me.

[rjbrown]

Fair enough. I like Chromecast's approach better from a user perspective, but I am probably somewhat biased by my experience in developing for all these devices as well.