Icebreaker - Revision history

Saoshyant at 23:05, 3 February 2008

2008-02-03T23:05:00Z

← Older revision		Revision as of 23:05, 3 February 2008
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.
Line 51:		Line 52:

	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]]

Nickmudd: /* Subversion */

2007-06-29T06:56:58Z

Subversion

← Older revision		Revision as of 06:56, 29 June 2007
Line 3:		Line 3:

	== Subversion ==		== Subversion ==
-	https://~~svn~~.xiph.org/trunk/icebreaker/	+	https://trac.xiph.org/browser/trunk/icebreaker
		+
	== Plans ==		== Plans ==

Nickmudd: /* Application */

2007-06-29T06:34:20Z

Application

← Older revision		Revision as of 06:34, 29 June 2007
Line 41:		Line 41:
	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.

Nickmudd at 07:23, 14 June 2007

2007-06-14T07:23:34Z

← Older revision		Revision as of 07:23, 14 June 2007
Line 2:		Line 2:
	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://svn.xiph.org/trunk/icebreaker/
	== Plans ==		== Plans ==

Nickmudd at 07:11, 14 June 2007

2007-06-14T07:11:26Z

← Older revision		Revision as of 07:11, 14 June 2007
Line 15:		Line 15:
	# 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 ==

Nickmudd at 23:16, 4 June 2007

2007-06-04T23:16:35Z

← Older revision		Revision as of 23:16, 4 June 2007
Line 21:		Line 21:
	see [[Icebreaker::UserWantedFeatures]]		see [[Icebreaker::UserWantedFeatures]]

		+	== Worklog ==
		+
		+	see [[Icebreaker::Worklog]]

	== Application ==		== Application ==

Saoshyant: there's no such thing as "OGG"

2007-06-01T08:14:24Z

there's no such thing as "OGG"

← Older revision		Revision as of 08:14, 1 June 2007
Line 24:		Line 24:
	== Application ==		== 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 ~~OGG~~ 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 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 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.	+	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 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.

Nickmudd at 05:01, 1 June 2007

2007-06-01T05:01:03Z

← Older revision		Revision as of 05:01, 1 June 2007
Line 20:		Line 20:

	see [[Icebreaker::UserWantedFeatures]]		see [[Icebreaker::UserWantedFeatures]]
		+
		+
		+	== 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 OGG 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.

Oddskool at 07:52, 31 May 2007

2007-05-31T07:52:18Z

← Older revision		Revision as of 07:52, 31 May 2007
Line 16:		Line 16:
	# 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)		--[[User:Nickmudd\|Nickmudd]] 18:54, 30 May 2007 (PDT)
		+
		+	== User Wanted Features ==
		+
		+	see [[Icebreaker::UserWantedFeatures]]

Nickmudd at 01:56, 31 May 2007

2007-05-31T01:56:57Z

← Older revision		Revision as of 01:56, 31 May 2007
Line 7:		Line 7:
	My plans are as follows:		My plans are as follows:

-	1. Written in Python.~~<br>~~	+	# Written in Python.
-	2. Metadata in database.~~<br>~~	+	# Metadata in database.
-	3. Playlists stored in database.~~<br>~~	+	# Playlists stored in database.
-	4. Playlist scheduling.~~<br>~~	+	# Playlist scheduling.
-	5. Backend/frontend design, possibly multible frontends.~~<br>~~	+	# Backend/frontend design, possibly multible frontends.
-	6. No web server needed, interface comes from TurboGears.~~<br>~~	+	# No web server needed, interface comes from TurboGears.
-	7. Minimal configuration, after all thats why I started the project.~~<br>~~	+	# Minimal configuration, after all thats why I started the project.
-	8. SQLObject will be used to work with any database.~~<br>~~	+	# SQLObject will be used to work with any database.
	--[[User:Nickmudd\|Nickmudd]] 18:54, 30 May 2007 (PDT)		--[[User:Nickmudd\|Nickmudd]] 18:54, 30 May 2007 (PDT)