Generic Podcast Framework

My thoughts...

Basically unless you are a "podcast network" like Revision3, I think it makes more since to have a "Podcasts" channel, then organize by category for the different podcasts. You could have a web interface to subscribe to specific podcasts or choose from popular ones. (similar in effect to the channel store). The popular/top/etc could be "subscribable" within the channel even. I wouldn't rule out having twit/rev3 shows in the "Podcast" channel, but it sure seems smarter than having each podcast with its own channel. Locating them all within one channel also creates the ability to show "new" (unseen) in a centralized place, etc. If someone has the proper "motivation" (read: financial backing), I think this could be something that would make it as a public channel. Part of me thinks it would be cool if it was free for some sort of basic setup with a subscription model for customization.. something cheap like $1/month? any takers? I have code spooling around in my head 😉

Tommy

"RoadRanger" wrote:

"nowhereman" wrote:
Has anyone considered (or is anyone working on) an open source, generic podcast channel?

So, now that you have developed it are you willing to "share" :)?

But of course. Anyone is welcome to the BrightScript source. I'll release it under a GPL license.

Can you send it to me? I've been trying to figure out how to add Podcasts to a Channel I'm working on but so far have had no luck as I'm still new to BrightScript and still trying to figure it all out. So far I've had to manually enter each Podcast file into my channel but that's obviously impractical considering the site I'm making it for has about 2 dozen different Podcasts with some having over 20 files. Many Thanks in advanced.

I'd like to point out that the current developer agreement does not allow channels containing code released under licenses that require Roku to distribute source or post notices. MIT, BSD, etc should be fine, but GPL, unfortunately, would not be.

5. Channel Application Restrictions and Requirements; Rights to Code
A. Subject to the Grace Period, Your Channel Application must at all times:
i. comply with the Documentation;
ii. comply with all applicable terms and conditions of this Agreement and all of the Program Requirements; and
iii. not contain any open source code or other restricted code that could require Roku to publicly post or display any third party notices or any modifications to such code.

"RokuPatrick" wrote:
I'd like to point out that the current developer agreement does not allow channels containing code released under licenses that require Roku to distribute source or post notices. MIT, BSD, etc should be fine, but GPL, unfortunately, would not be.

5. Channel Application Restrictions and Requirements; Rights to Code
A. Subject to the Grace Period, Your Channel Application must at all times:
i. comply with the Documentation;
ii. comply with all applicable terms and conditions of this Agreement and all of the Program Requirements; and
iii. not contain any open source code or other restricted code that could require Roku to publicly post or display any third party notices or any modifications to such code.

My main reason for leaning toward the GPL whenever possible is that it requires developers to publish the code for their derivative works. BSD style licenses do not have that requirement. Would the MPL be compatible with the developer agreement?