From Definitelynotsafe Wiki

Contents 1 mp3d v. 1 2 Thinking About mp3d v. 2 2.1 Sprint (Hack Day) 2.2 A slightly jumbled collection of thoughts 2.2.1 Language/Framework 2.2.2 Features 2.2.2.1 Already existing features 2.2.2.1.1 Automatic indexing of uploaded files 2.2.2.1.2 .m3u generation 2.2.2.1.3 .tar generation 2.2.2.1.4 Squeezebox integration 2.2.2.1.5 Search 2.2.2.1.6 HTML generation 2.2.2.2 New features we want 2.2.2.2.1 Throughput Limiting 2.2.2.2.2 Built-in Flash music player 2.2.2.2.3 Through the web upload 2.2.2.2.4 Dynamic playlist support for Flash music player 2.2.2.2.5 Audio tag playback 2.2.3 Division Of Labor

mp3d v. 1

"mp3d is a humble web interface for music libraries"

• Mercurial Repository

• mp3d in Action!

Thinking About mp3d v. 2

Sprint (Hack Day)

When: We discussed picking a day between 10/16 and 10/18.

Where: TBD

What

• There should be a list of things we plan to accomplish on that day here.

A slightly jumbled collection of thoughts

(We can collaboratively turn this into some semblance of a Project Plan.)

Language/Framework

• The consensus seems to be Ruby for the next iteration. Probably with some web framework. Camping seems out of the running. Rails seems like overkill for this project. Word on the street is that Sinatra and Ramaze are pretty OK and reasonably lightweight, but I (PB) don't have any experience with either. Can anyone weigh in?
  • I looked at Sinatra briefly. It is *dead sexy*. But I'm not yet convinced that a "Web App" framework fits mp3d. E.g., we have no need for persistent storage. We only have like two views. CGI is not a bad model and I do like its simplicity. cgi.rb with a few convenience layers might work pretty well. But let's experiment and see what we get. -joe
    • Is user authentication something we might want at some point? That's the one case I can come up with where persistent storage might come in handy. There's this for Sinatra: http://github.com/maxjustus/sinatra-authentication -PB

Features

Already existing features

We should probably implement these first.

Automatic indexing of uploaded files

cron job

.m3u generation

Could use an upgrade in terms of flexibility. (Add/remove songs rather than just take all-or-nothing from listing or search results.)

.tar generation

Squeezebox integration

Search

• Options: Match case, Restrict to whole words.
• Fuzzy search. Is this compelling enough to bother?

HTML generation

Should use a template system.

New features we want

In approximate decreasing order of priority.

Throughput Limiting

The basic objective is to ensure that when the mp3d is run over a residential internet connection, heavy usage doesn't get in the way of the line's subscribers' internet Fahrvergnügen. Throttling doesn't just help the subscribers, though: it's a great way to give peace of mind to other users who are worried about inadvertently using more than their share of resources.

An optimal solution might require some fancy QoS policies at the router, but the objective here is to get a "good enough" implementation working in user-space code.

A few questions to answer to figure out how to do this right:

• How much upload capacity needs to be reserved to allow normal internet usage?
• Is it better to limit the total throughput or limit per-IP or both? The former leads to more optimal resource allocation; the latter is "fairer".

A reasonable option looks to be mod_cband for Apache. Its CBandSpeed and CBandRemoteSpeed are basically what we're looking for to accomplish the above.

Built-in Flash music player

One song or with playlist support? In the former case, http://developer.yahoo.com/mediaplayer/ looks promising.

Through the web upload

Using something like http://swfupload.org/

Dynamic playlist support for Flash music player

Add/remove individual songs, or add a whole set of search results.

Audio tag playback

Probably The Way of the Future.

Division Of Labor

How do we avoid stepping on each others' toes?

• Mercurial + Bitbucket do a lot already.
• Can the project be split into parts with "owners", or is Joe just going to be the Mutex Man?
  • For reasons unexplained, she loved the Mutex Man.
  • So the branch-and-pull workflow Jørgen and I used fits poorly with Mercurial. It's very difficult to cherry-pick some of his changes. We may have to shift to dealing in patches. At which point ... ... ... I could be persuaded to try git, which is way better at this style.