On Metadata
The last release (Ubuntu 7.10) was the first in which we shipped Tracker enabled by default; this service runs in the background and indexes all of your files, storing information about them in a metadatabase which can subsequently be searched. The two main ways of searching are through the deskbar-applet (press Alt+F3) and within the nautilus file manager (press Ctrl+F).
That’s all well and good, but since we now have a metadatabase and indexer, what else can we do with it?
The first thing that comes to mind is improve those applications that attempt to maintain their own metadatabase; those that tend to be the primary apps that we use because they manage our all-important content. I’m going to pick on Rhythmbox here since it’s our default music manager, but the same ideas can be applied to our default photo manager, F-Spot, or any other application concerned with content.
A no-brainer is that Rhythmbox no longer needs to worry about walking directory trees, keeping inotify watches on them, identifying media files, etc. Tracker already does all of that. All we need to ensure is that tracker collects all of the metadata that Rhythmbox will need to start with — we expect it to come along and add additional metadata, such as the last time I played the track, where the album cover thumbnail is stored, etc.
Another thing you get to eliminate is the concept of “the Library”. Your entire home directory is already indexed, why care about partitioning it? We can just show the user all of their music, or all of their photos. Immediately. With no need to import from one arbitrary location on disk to another.
Tracker should then grow removable device support, indexing files on removable devices just as it does on the primary filesystem; but keeping mount-relative paths to the files and remembering particulars such as serial number, label, etc. for the device they were found on. This has immediate benefit for Tracker anyway, I can search for a presentation and I’ll be told which USB Key I wrote it to so I can find it again — I’m terrible for losing presentation slides after I’ve given the associated talk.
All Rhythmbox then needs to do is query Tracker for removable devices containing music, and show them as icons in the panel; the contents are already indexing — or if you’ve already used that device, indexed (no more wait for it to index my 40GB media player every single time I insert it). Since there’s just one metadatabase behind this, you may as well add an “All Your Music” option to the top which amalgamates the collection of music on your filesystem and removable devices, eliminating duplicates; this would be the thing you’d share, getting rid of yet another bug.
We then don’t need import dialogs. If I plug a media player in (or a camera, this applies equally there), the content immediately shows up in my browser. The only question we need ask the user is whether they wish to add the music on the device to their local collection, and that can be done inline in the window rather than with an obtrusive dialog. For F-Spot the experience would be that on plugging in a camera of photos, the main F-Spot window would open with the photos already in place (or appearing) in the rest of your collection and a “add these to your collection?” bar at the top — since you have the full app, dealing with adjusting images on import, or removing them entirely is much easier than fiddling inside an option-filled dialog.
The only other backends we’d need would be for remote media such as shared music –why isn’t there a shared photos standard yet?–, online content such as last.fm or flickr and devices that don’t act like disks; there are still some media players and cameras out there which are designed around import/export APIs.
