Advogato: Blog for avriettea

The iTunes disk

I've been ruminating on this iTunes disk notion. We already have this silly iDisk thing which is a wrapper around webdav. At one point, we were able to mount ftp connections as volumes (although I think this has been turned off by default; It was a pain in the ass with the early copies of Safari, but I just don't use ftp anymore – or Safari, for that matter). Anyways, why not have an "iTunes Disk" functionality? It's really not that hard (in the sense that it's frequently easier to scale up and out code than to start from scratch. Sometimes it isn't. I'd bet, though, that the QA and vetting process for such a feature would take longer than the coding) as most of the code is written already.

Live preview and columns

The Finder has column display, so hierarchies are not hard to figure out. There's live previewing in the Finder already, both for small icons and "click-hovering" (in column display, tap the icon once, it shows up enormous in the rightmost column – you can actually play m4p and m4b files from here, if iTunes has the right credentials!). All they'd have to do is make it pretty (making it simple/elegant is not very hard, as the users are already using the finder, and the display in iTunes wouldn't change). The functionality is there.

Browsing through iTunes data, including rendering of data through iTunes tokens (so they're not decoupled)

What reason would they have for not extending this any further? There are other examples of this, such as the "burn folder" functionality. Furthermore, Microsoft has kind of taken the idea and run with it in Vista (and to a lesser extent, XP). There's a whole lot of stuff you can do in explorer.exe without really launching an application. Isn't this usually the other way around? I'm not saying Vista has a slicker-n-guano human interface, just that there are features that seem sensible to have which aren't in MacOS (to be fair, there's a lot of garbage I don't want in Windows).

What seems to be missing from the equation, though, is that performance-tuned backend. As we've now hit twenty times the storage of the original iPod, we're still using the same stuff. I wholeheartedly agree with the notion of having it be hacker-friendly, and XML is a reasonable way to do that. However, when you provide somebody with XML they have to either write their own lexer/parser or grab an API from somebody. Why not, as a couple people suggested to me, use something like sqlite? I wouldn't be having these irritated "seek...seek...seek" times between book parts, gapless cd's, and so on. Seems to me that SQL is fairly agnostic as an interface goes. Similar to XML's being an agnostic data exchange format. So what would be wrong with providing either APIs (I am sure they would make sure the snake is kitted out) or SQL hooks via their ODBC stuff, or even appleshare hooks. If you really, really want XML, there's no reason you couldn't have a select_as_xml() function built into the API. I suppose you could probably spit out an iTunes library on an interval, or when things were changed (changes tend to be not-often and come in groups) for applications that insist on frobbing the XML.

As I was mulling all this over, it occurred to me that it's not unlike the NeXT vision (that is, plugins to the finder, rather than heavy applications), and of course OS X is full of next relics. So why wouldn't they have done this already? I could write software that generated a library for iTunes to read, but I have no idea how to handle writes, which of course the software would have to do.

Syndicated 2007-07-31 15:37:00 (Updated 2007-07-31 16:43:57) from Alex J. Avriette

31 Jul 2007 avriettea » (Journeyer)