« The Real Red vs. Blue | Main | Alex and Io »
August 24, 2004
Implementation Thoughts for SOULTRAIN
Last week I posted my ERD for Project SOULTRAIN (Sound Of Unreasonably Lossless Truly Ridiculous Audio (Array) In a Network). The original goal of Project SOULTRAIN few recall, so I'll reproduce it here.
I hate RIAA. I hate record labels. I hate promoters. On the other hand, I love music. I want to have a single copy of whatever CD I want to own, and I want to use that copy exactly once. That one time that I use it, the following need to take place:
A perfect disc image must be made.
By this I mean, I want an image which is indistinguishable from the original when burned to CD. Near as I can tell, there is a way to do this with the command cdrdao read-cd.
An Ogg/Vorbis or Mp3 cached copy of each track is made.
This is because morons seem to like lossy music, because that way they can cram more of it on their cheap iPod ripoff.
All metadata is stored in my massive and friendly database.
I want to be able to search the database against any criteria I can imagine. Former band members, instruments used, “double-axe attack,” anything. Cover art, liner notes and lyrics count.
Then I want to have two other little bits laying around: a CD regenerator, and a plugin for whatever music player I'm using.
So today my thoughts drifted back to this. I want to pick my implementation language and answer a few other questions. Namely, whether or not I should couple tightly to PostgreSQL (I think I probably should) and whether or not I should make use of triggers and stored procedures. I have mixed feelings about triggers and stored procedures, because I don't want to use Pl/PgSQL, and using anything else would make it even more unlikely that this software will be reused. I'm looking at putting many man-months into this (not to mention my own specific database) and I think other people may wish to use it, so it's probably in my best interest not to couple it too tightly to any “weird” technology. But I also don't want to do this if it's going to be a drag.
Here's the language break-down:
| Language | Pro | Con |
|---|---|---|
| Ruby | Most fun, probably, second-best glue coding language, C extensions are probably easiest | Tendancy for sloppiness, low possibility of 0D, PostgreSQL module sucks |
| Io | Second most fun, worst glue coding language, C extensions are impossible but a fork of the code or embedding Io in a greater system with primitives for dealing with everything else is possible and might be easy | Seals the casket with respect to reuse, would wind up writing a lot of C ultimately, language is far from stable |
| Python | Best libraries, great portability, likelihood of reuse very good, probability of 0D very high | Least fun (now that I want to try other languages), probably slowest (if it matters) |
My urge is toward the first two, because they're more fun. If you can use a fun language in your own projects, when can you use one? But the other concerns may wind up weighing it down.
The other possibility is to build different portions of it in different languages. This is probably the most compelling. I wrote a demo in ECPG the other day, just to see how bad it was, and it wasn't that bad (though it looks like handling large objects is quite a chore). So there is the possibility of writing some sort of “Objecty-C” wrapper for the database in ECPG and then building on that for both Ruby and Io support, and doing the actual work there. I might even bother to learn about extending Python at that point, assuming I have a fleshed-out and fully tested C library to drive the thing. But then we lose on the flexibility angle with respect to homebrew queries. Perhaps the best thing to do is to do that and then provide a way of speaking directly to the database. I have serious doubts about object-relational interfacing, because it seems to miss out on the flexibility of the database which is it's fundamental merit. But maintainability being the other concern, one doesn't want to expose the database to too much fiddling.
What a quandry…
Update: I've discovered that Io includes something called libdbi, a C-based database abstraction layer, which comes with PostgreSQL support. Making it happen in the build automatically may be quite a trick, but it seems like it's definitely doable. Additionally, I worked on Ruby's PostgreSQL module and I can get it to compile in Linux but not on the Mac. Further investigations are necessary as to the reason why this is, but I suspect very strongly that I'll be able to get it to work too.
Posted by FusionGyro at August 24, 2004 03:22 AM
Trackback Pings
TrackBack URL for this entry:
http://www.clanspum.net/~fusion/blog/admin/mt-tb.cgi/8