client caching

David E. Smith (dave nospam at technopagan.org)
Fri, 26 Mar 1999 04:45:03 +0000 (GMT)

(ObIntro: Hi, I'm Dave, I'm new here.)

A search of the archives didn't turn up anything about this, but if I
missed it, you're probably all highly competent flamers. :)

I'm patching cdindex support into dcd, my ultraslim CLI CD player. But I
don't want for users to have to connect to the 'net just to play a CD - I
know that would bring me no end of annoyance. So I'm looking at some kind
of client-side caching of CD info.

I've got a (very simple) scheme in mind, which I'll detail below. But
before I start the serious coding, is anyone else working on a
cdindex-capable CD player? It'd be really keen if various clients could
interoperate, share local cache, save disk space and emit 20% fewer
pollutants. And if someone else has already done it, I'll, er, borrow
their code.

My scheme is the really simple one, which will work on Linux and any other
*nix that supports long-ish filenames (32 characters, to be precise).
Basically, take the output from get.pl (simple ASCII, easy to parse by
just about anything) and store it in a file whose name is the discid (the
SHA hash). Probably in ~/.cdindex. (Maybe in a central location like
/var/cdindex?)

Optionally, for CDs that are requested but for which database info isn't
locally available, store the discid in ~/.cdindex/wanted (for later
retrieval). Since any filename <32 characters is guaranteed not to clash
with a discid, clients could save settings in there too, saving a
directory inode too :)

Comments?

...dave