Work from the original report was contributed by:
Hart Lambur (hal2001@columbia.edu)
Lawrence Wang (levity@gmail.com)
Our application requires Java, Apache with mod_python, Apache Ant, MySQL, Matlab, and a scheduling app such as cron. There are no installation or configuration instructions because our application is hosted. The only client-side requirements are iTunes, and a Web browser that supports Java and flash.
admin.psp: Displays log messages, and user information keeping the administrator aware of how and when the system is being used.
albuminfo.psp: The template for album information.
applet.psp: This file is included in cutunes.psp and welcome.psp; it contains the HTML that embeds the Java applet that syncs users' music with our server.
artistinfo.psp: Template for artist information.
common.psp: This file, included on every page after login, contains frequently-used methods as well as the check to make sure the user accessing the page is logged in and redirect otherwise.
cutunes.psp: Template for displaying individual and community top charts.
editprofile.psp: Allows the user to edit their name and password.
header.psp: This file, included on every page after login, contains the title and links at the top of every page.
invite.psp: The file allows users to send an invitation email to their friends via a web-interface.
login.psp: This page has a username/password form, with an option to enter your UNI instead if you are a new user. We limit usernames to UNIs to simplify the process of confirming that new users are Columbia students.
neighbors.psp: Template for compatibility information.
newuser.psp: This page sends an email to the submitted UNI with a generated password, and stores the new user's information in the database. To send the email, it opens a pipe to the ssmtp program, which forwards email to the mail server specified in its configuration, which in this case is send.columbia.edu. newuser.psp also makes use of the python-ldap module, which looks up the submitted UNI on ldap.columbia.edu to retrieve the user's name and major. If this information is available, it is stored in the database and retrieved by various other pages so that users can know more about the people with whom they share musical tastes.
recs.psp: Displays recommendations.
songinfo.psp: Displays information for a single selected song.
userprofile.psp: Template for user profiles.
welcome.psp: This page contains an introduction to the project and FAQ, as well as an option to sync your data.
Below is the current database schema we are using. All the top_* tables are used to cache the community wide top 40 charts. All the rec_* tables are used to cache the recommendation tables.
table top_songs ( play_total integer, artist char(100) not null, album char(100), name char(100) not null, id integer );
table top_songs_week ( play_total integer, artist char(100) not null, album char(100), name char(100) not null, id integer);
table top_albums ( play_total integer, artist char(100) not null, album char(100));
table top_albums_week ( play_total integer, artist char(100) not null, album char(100));
table top_artists ( play_total integer, artist char(100) not null);
table top_artists_week ( play_total integer, artist char(100) not null);
table message_logs ( id integer primary key auto_increment, log_time datetime not null, error bool, function char(50), message char(200));
table sync_logs ( id integer primary key auto_increment, user_id integer references user (id), sync_time datetime not null, version char(25), message char(40));
table user ( id integer not null auto_increment, name char(30) not null, password char(40) not null default 'xxxx', last_sync datetime not null default '2005-01-01 00:00:00', primary key (id), firstname char(30), lastname char(30), dept char(30));
table song ( id integer not null, name char(100) not null, artist char(100) not null, album char(100), year integer, length integer, primary key (id));
table has_song ( user_id integer not null, song_id integer not null, last_played datetime, play_count integer, play_count_week integer, foreign key (user_id) references user (id), foreign key (song_id) references song (id), primary key (user_id, song_id));
table compatibility ( user_id integer references user (id), other_user_id integer references song (id), rating integer, primary key (user_id, other_user_id));
table artist_dist ( artist char(100), other_artist char(100), rating integer, primary key (artist, other_artist));
table compatibility_week ( user_id integer references user (id), other_user_id integer references song (id), rating integer, primary key (user_id, other_user_id));
table rec_song ( user_id integer references user (id), recommendation char(200), rating integer, primary key (user_id, recommendation, rating));
table rec_song_week ( user_id integer references user (id), recommendation char(200), rating integer, primary key (user_id, recommendation, rating));
table rec_album ( user_id integer references user (id), recommendation char(200), rating integer, primary key (user_id, recommendation, rating));
table rec_album_week ( user_id integer references user (id), recommendation char(200), rating integer, primary key (user_id, recommendation, rating));
table rec_artist ( user_id integer references user (id), recommendation char(200), rating integer, primary key (user_id, recommendation, rating));
table rec_artist_week ( user_id integer references user (id), recommendation char(200), rating integer, primary key (user_id, recommendation, rating));