I have been trying to learn inkscape so that I could have a vector based version of the HPR logo. This would be useful for printing out large posters for use at the Linux Festivals that we attend. I had been following the excellent tutorials over at screencasters.heathenx.org, and while their site is brilliant, my progress has been very slow. So slow that a new year festival season is upon us and I had made no progress. Finally I just gave up and asked them for help. Not only did they say yes but they asked if they could “tweak it slightly”. You can see the results of that here.
Spurred on by that success, I’m putting the call out for some help with a new version of the scheduling system for HPR. I’ve been working on it for some time now and it’s also going nowhere. I’d like to release it so that it can be used by anyone who wants to setup a syndicated community podcast network like ours. I’ve put some thoughts into the design and would like to get involvement from people with experience in doing this type of thing.
FAQ:
What is it called ?
The HPR Scheduling System, until something better is suggested.
What License will it be under ?
AGPL v3 (GNU Affero General Public License) because this is a web application and Bradley would be impressed.
How will it work ?
- Community members and spammers will upload the shows via a custom PHP component integrated into an off the shelf frontend CMS. That will be kept in quarantine until it is approved.
- The scheduling manager will verify the show, approve it and change priority.
- The backend will transcode it and add it to the database based on the scheduling rules.
- A cron job will:
- ssh static RSS 2.0 Compliant XML feed to the front end system(s)
- ssh a html/xml file listing upcoming shows to the front end system(s)
- will upload the new episode to archive.org
Why split it up ?
The idea is to provide two security zones. The backend with restricted access and a frontend that is public facing. Reusing a popular CMS like wordpress will limit the scope for compromise as the RSS 2.0 Compliant XML will be the source of the data on the site and can be reloaded at any time. The only component we need to manage is the file and metadata upload.
The backend will contain the actual database and user information and is intended to be managed via ssh and command line tools. This could be run on a home pc or on a cheap vps running Debian/Fedora/Slacker media. As this code will be reviewed by a lot less people than the frontend, we can restrict the access to trusted keys etc. Using archive.org will allow others to avail of free hosting for media files.
What will it be written in ?
The backend will be written in perl/mysql and will be driven by cron, which will produce a RSS 2.0 Compliant XML feed.
The frontend will be any CMS (WordPress/Drupal/Joomla) with a plugin to federate RSS 2.0 Compliant XML feeds.
Why use RSS 2.0 Compliant XML ?
It’s a standard and it supports categories (series), tags, host addresses etc. It provides a clean, common well defined interface.
Why use PHP/MySQL for the frontend ?
That’s what hosting providers provide cheaply and so that’s what WordPress, Drupal, Joomla are written in.
Why use perl/MySQL on the backend ?
That’s what comes standard on many linux distros and has a lot of modules available in cpan.
Why not use Python/PHP/C/C++/Java/Mono/* instead of perl/php ?
It’s what I know so as I’ll probably be dumped with doing most of this, I want to make sure that I can trust the code.
Seriously Perl/php ?
If you want to do this in another language then fine but you are accepting been the project lead for at least two years – ok.
Where will the code be stored ?
Don’t know yet – HPR FTP Server 🙂
But Project XYZ already does this ?
Great. Send me a link – job done.
What help do you need ?
People with PHP, Perl, MySQL, DBA, security skills.
Who do I contact ?
email: admin@hackerpublicradio.org
