> 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.
As far as I know no-one has done this. I would love for you to do
this, and the integrate your code into the client code base. I'm
looking for a volunteer to take on the client side of things and create
DLLs/shared libs with the lookup/submission/local cache code all
wrapped up and easy to use...
> 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 :)
I don't really see a problem with that. However, I think there will be
people who will object to the use of an inode for each CD in their
collection. Maybe something like Berkeley DB/GDBM could be used to
store the data without adding much overhead to the client software.
--ruaok Freezerburn! All else is only icing. -- Soul Coughing
Robert Kaye -- robert nospam at moon.eorbit.net http://moon.eorbit.net/~robert