Icebreaker: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
No edit summary
mNo edit summary
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{historical}}
== Introduction ==
== Introduction ==
Icebreaker is a playlist authoring/scheduling system for Icecast. It uses a database to store playlists and scheduling data. Icebreaker's main objective is to be easy to use, so that writing playlists by hand can be avoided. Icebreaker is being designed to use a web-based interface through TurboGears. Icebreaker is _NOT_ a web-based streamer or a client.
Icebreaker is a playlist authoring/scheduling system for Icecast. It uses a database to store playlists and scheduling data. Icebreaker's main objective is to be easy to use, so that writing playlists by hand can be avoided. Icebreaker is being designed to use a web-based interface through TurboGears. Icebreaker is _NOT_ a web-based streamer or a client.


== Subversion ==
https://trac.xiph.org/browser/trunk/icebreaker


== Plans ==
== Plans ==
Line 15: Line 19:
# Minimal configuration, after all thats why I started the project.
# Minimal configuration, after all thats why I started the project.
# SQLObject will be used to work with any database.
# SQLObject will be used to work with any database.
--[[User:Nickmudd|Nickmudd]] 18:54, 30 May 2007 (PDT)
 
== Design ==
 
see [[Icebreaker::Design]]


== User Wanted Features ==  
== User Wanted Features ==  
Line 37: Line 44:
The main focus of this project is ease, and I will facilitate use in these ways:
The main focus of this project is ease, and I will facilitate use in these ways:


1. Simple Interface, very self-explanatory.
1. Simple Interface, very self-explanatory.<br>
2. Minimal configuration. No web server needed, no PHP, extremely easy to get up and running. (Possibly) a few Python Libraries to install. One short configuration file. However, Ices will need to be configured to accept input from a script.
2. Minimal configuration. No web server needed, no PHP, extremely easy to get up and running. (Possibly) a few Python Libraries to install. One short configuration file. However, Ices will need to be configured to accept input from a script.<br>
3. Database agnostic. If no database server is installed, SQLite will work perfectly in it's stead.
3. Database agnostic. If no database server is installed, SQLite will work perfectly in it's stead.<br>


My goals in this project are not overly ambitious, and will contribute greatly to media enthusiasts like myself. I have set up a project page on Google Code (http://code.google.com/p/icebreaker/). I have not released any code because the code is not usable by anyone other than myself for the initial development. Soon I will add the code I have completed to the project page after adding database support to the Ices-callable script. I realize this description is very short in comparison to the 7500 character limit, but a few details are currently "up in the air". Namely, how I will handle scheduling and whether or not I will daemonize the backend. I have several ideas on how to handle the internals, but it's too early to tell how it will work. Very soon I plan on doing a few flowcharts to illustrate the architecture of the project, and the various ways it may manifest.
My goals in this project are not overly ambitious, and will contribute greatly to media enthusiasts like myself. I have set up a project page on Google Code (http://code.google.com/p/icebreaker/). I have not released any code because the code is not usable by anyone other than myself for the initial development. Soon I will add the code I have completed to the project page after adding database support to the Ices-callable script. I realize this description is very short in comparison to the 7500 character limit, but a few details are currently "up in the air". Namely, how I will handle scheduling and whether or not I will daemonize the backend. I have several ideas on how to handle the internals, but it's too early to tell how it will work. Very soon I plan on doing a few flowcharts to illustrate the architecture of the project, and the various ways it may manifest.
Line 46: Line 53:


Though I wont contribute specifically to any one of your projects in code, I feel that my project will enhance other xiph projects.
Though I wont contribute specifically to any one of your projects in code, I feel that my project will enhance other xiph projects.
[[Category:Icebreaker]]

Latest revision as of 04:47, 23 June 2016


Introduction

Icebreaker is a playlist authoring/scheduling system for Icecast. It uses a database to store playlists and scheduling data. Icebreaker's main objective is to be easy to use, so that writing playlists by hand can be avoided. Icebreaker is being designed to use a web-based interface through TurboGears. Icebreaker is _NOT_ a web-based streamer or a client.

Subversion

https://trac.xiph.org/browser/trunk/icebreaker

Plans

My plans are as follows:

  1. Written in Python.
  2. Metadata in database.
  3. Playlists stored in database.
  4. Playlist scheduling.
  5. Backend/frontend design, possibly multible frontends.
  6. No web server needed, interface comes from TurboGears.
  7. Minimal configuration, after all thats why I started the project.
  8. SQLObject will be used to work with any database.

Design

see Icebreaker::Design

User Wanted Features

see Icebreaker::UserWantedFeatures

Worklog

see Icebreaker::Worklog

Application

I run a Icecast stream for the use of myself and my friends, and while making playlists for it, I was very overcome by the enormity of the task. I have a modest Vorbis collection by some standards, 2500 tracks. I pity anyone that has ever tried to make playlists for a large streaming site with who knows how many tracks. What's more, I can't be bothered to switch playlists out all the time. So the natural progression seemed to be a simple drag-and-drop interface to create and schedule playlists.

I plan to use a separate backend from the web interface, so that a X-based frontend could be added eventually, or support could be added in an existing media application. SQLObject will be used to provide support for multiple databases with one set of code. I will try to minimize configuration to media path, and database connections, and password for the interface.

I have some code written, a script that populates a database, and a script that will be called by Ices and Icecast that provides the next track to play. I wish to include searching/adding media to a playlist based on metadata, as the populate.py script parses Ogg tags and adds them to the database.

The frontend will be based off of TurboGears (http://www.turbogears.org) and could be packaged as a python egg, separately or included with the source for the backend. In the event that no playlist is scheduled, there will be a random playlist that will be automatically generated. Future plans are to integrate with Google Calendar, to display to any users which playlists will be scheduled. Another of my plans is to research integration with Icecast, to add support for controlling it. I've been thinking about this project and planning it since December, and I am extremely excited.

The main focus of this project is ease, and I will facilitate use in these ways:

1. Simple Interface, very self-explanatory.
2. Minimal configuration. No web server needed, no PHP, extremely easy to get up and running. (Possibly) a few Python Libraries to install. One short configuration file. However, Ices will need to be configured to accept input from a script.
3. Database agnostic. If no database server is installed, SQLite will work perfectly in it's stead.

My goals in this project are not overly ambitious, and will contribute greatly to media enthusiasts like myself. I have set up a project page on Google Code (http://code.google.com/p/icebreaker/). I have not released any code because the code is not usable by anyone other than myself for the initial development. Soon I will add the code I have completed to the project page after adding database support to the Ices-callable script. I realize this description is very short in comparison to the 7500 character limit, but a few details are currently "up in the air". Namely, how I will handle scheduling and whether or not I will daemonize the backend. I have several ideas on how to handle the internals, but it's too early to tell how it will work. Very soon I plan on doing a few flowcharts to illustrate the architecture of the project, and the various ways it may manifest.

I plan on having this application feature complete about 75% through the summer, as I am already greatly obsessed with it and am only abstaining from the project to focus on my schoolwork. I have the entire summer to work on this project if it is accepted and will spend at least 30 hours a week on it. Almost everything I code is media-oriented. I usually write converter scripts in python or bash to manipulate files. I am most comfortable in Python and I have done a little work in C. I also took a course in VB.net and hated every minute of it. I dont think of myself as a programmer, but I greatly enjoy making things and enjoying the outcome of my labor.

Though I wont contribute specifically to any one of your projects in code, I feel that my project will enhance other xiph projects.