«« Agile Data Serialization Management Urgent My Foot! »»
blog header image
AudioMan's Repository to Use a Database

I think you guys are right: I've hit the tipping point with the AudioMan repository. Using objects and the Java Collections Framework was good to start but now the features I need, like threadsafety, would take too much custom development and maintenance time to be practical.

So I will concentrate on getting a database in there for the next little while. The most promising database is HSQL, formerly Hypersonic, a database completely written in Java that supports SQL. Thanks Jim, for finding it.

Kibbee also suggested Xindice because AudioMan currently uses XML. That's true, but the XML is only in the repository implementation and would be completely replaced by a new database. So Xindice would have to offer compelling features over HSQL besides its XML buzzwords compliance (now with 50% more XPath!).

If you find any other databases that would work well with AudioMan, let me know. Here's what the ideal database would look like:

1. Callable from Java but still performant
2. Portable to the big three operating systems (Windows, Linux and Mac OS X) but preferably to any system with a Java VM
3. Easy to install (or just copy) to a client machine (NOT something like mySQL)
4. Easy to uninstall
5. Small file(s) size overhead
6. Small memory footprint overhead
7. Negligable impact on or coupling with the user's operating system (registry keys)
8. Can handle the data for a collection of at least 5,000 songs (tags, locations, playlists. etc)
9. Can be configured by the Ant build script
10. Can be legally distributed with the AudioMan installer
11. Easy to use API (SQL is good)
12. Can be used in a multi-user environment, either through separate installations (ie. in the user's home directory) or concurrent sub-databases

Of course, easy and small are relative terms ... but they are something to aim at.

Preferably the user shouldn't even be aware that AudioMan uses a database. Apparently iTunes uses a database and exposes XML files to the file system transparently. Obviously AudioMan can't do that but it gives you an idea of the kind of seamless integration that joe sixpack users like.

Remember that AudioMan is an end-user application targetted to regular people. We can't have them installing or configuring a database themselves. The installation should be so painless that they don't mind doing it often (like Mozilla's installer: download... click-click-click-click-done).

Posted at March 25, 2004 at 07:20 AM EST
Last updated March 25, 2004 at 07:20 AM EST
Comments

Speaking from past experince:

The installer should be as familar as possible. InstallShield or something that you often see is important because the average user does not like new things.

Also, installation is one of the most important, and most overlooked, user experience there is. If I don't like the choices I have (or have to make) during installation, I will abort... as will many others.

Users should always be directed one way or another, but not both. The best bet is 'We are going to do it this way, click here to NOT do it that way' ... opt-out is the way to go. The less thinking the better. The drop-off rates should be consistent throughout the installation process, or else you are doing something wrong.


And please stop refering to us as 'joe sixpack' :)
Joe Sixpack is the person who will pay you money for software... more advance users will just download the crack for free...


T.

» Posted by: Travis at March 25, 2004 01:27 PM
Google
 
Search scope: Web ryanlowe.ca