Roku Developer Program

[destruk]

Duplicating the functionality of the Roku Channel Store is a violation of the developer agreement. So maybe that's why the functionality isn't there?
if all you want is a channels list - they have that already - http://www.roku.com/channels/#!browse/m ... by-popular

Why duplicate what is already here?

[gonzotek]

"destruk" wrote:
Duplicating the functionality of the Roku Channel Store is a violation of the developer agreement. So maybe that's why the functionality isn't there?
if all you want is a channels list - they have that already - http://www.roku.com/channels/#!browse/m ... by-popular

Why duplicate what is already here?

"bbefilms" wrote:
One API usage scenario might be a widget that could be placed on websites and blogs that lists the latest/most popular/craziest channels; you don't think that this kind of widespread, free promotion would help sell units?

There are other cases where a channel list api could be useful as well. I'd like to show the channel list in Remoku, and would direct people to the Roku web channel store to install if they find things they want. I definitely don't want to do Roku user authentication from within remoku and wouldn't expect Roku to want this either, I just would like to show the channel list(s).

[RokuJoel]

"bbefilms" wrote:
Business case? How about that it appears insane that you aren't enabling developers to provide end users of your product with critical content information. One API usage scenario might be a widget that could be placed on websites and blogs that lists the latest/most popular/craziest channels; you don't think that this kind of widespread, free promotion would help sell units?

First of all, *I love APIs* and am personally in favor of doing all kinds of things like this, and everybody I work with knows exactly how I feel about it, but in order to make something happen there needs to be some well thought out reasoning behind it besides "APIs are cool", or "we could sell a bunch of boxes".

That is why I asked if you could think of a business case.

- Joel

[wzwor]

The business case for a directory service or api is the hope that you will sell more Rokus because...

1) People will find content more easily. The more appealing content they find, the more attractive the device will be.
2) Developers will enjoy more success because people can more easily uncover he hidden gems. successful developers will make more content.
3) With proper tagging, Roku and its developers can learn what people like and target areas of interest for future development.

So, learn about your customers, help your developers learn about your customers, and help your customers find the content they want more easily.

[bbefilms]

"RokuPatrick" wrote:

I doubt private channels would ever be indexed publicly -- They're usually private for a reason, if the developer wants people to know about their channel, they'll let people know and/or submit it for the public channel store.
Patrick

That's incorrect; my guess is that many developers/publishers create private channels because they enable you to bypass the red tape of submission to the Roku channel store process and they're immediately available, not necessarily because they need to be unknown. Frankly, it's the private channels that are the interesting ones. Suggest all private channels should have the ability to be discoverable. And please make an API.

[destruk]

If private channels are discoverable, there isn't any reason to make them private. I think we'd lose about half of the channel developers here if that had to happen.

[renojim]

^ What he said. I'd be very unhappy if all of my private channels were discoverable.

-JT

[bbefilms]

"renojim" wrote:
^ What he said. I'd be very unhappy if all of my private channels were discoverable.

-JT

By default, they should not be discoverable but being discoverable should be an option. Then, I'm probably the only one here who thinks a channel API is essential for Roku to thrive, as is a software-only ROKU platform (e.g. a true Roku app for my iPhone, desktop etc.).