On Sun, 2007-12-16 at 18:22 -0500, David Zeuthen wrote: > Hey Alex, > > (Sorry to continue bombarding you with super long mails and patches) > > Here's a cdda:// backend for gvfs. Before going into details (and some > minor, probably easily fixable, architectural issues I've identified) > it's probably useful to answer the question "Why a cdda backend?" since > that question was asked here > > http://mail.gnome.org/archives/gnome-vfs-list/2005-August/msg00001.html > http://mail.gnome.org/archives/gnome-vfs-list/2005-August/msg00022.html > > It seems the main objections to that new cdda module for gnome-vfs were > > - would pull gstreamer into the client apps
Which client app would want to deal with audio CD data without pulling in some sort of multimedia framework? > - seeking didn't work > > - file manager not a good UI for ripping songs; better to launch > the cd player That's still current. > However, that ignores several fundamental problems > > - libcdio / libparanoia isn't the API application programmers > should use (however, gio is) GStreamer is, to deal with sound data. > - nasty locking issues when doing things decentralized (if it's > up to the software to do the raw device access it might do > uninformed things like using O_EXCL) > > - duplication in every app (extraction, meta data retrieval) How will you export the (very as-hoc) errors from the underlying libraries? How do you export the MusicBrainz Disc ID, or FreeDB one? > So I wrote the attached cdda module because with gio/gvfs I think it > actually makes sense have a cdda:// backend (also, and sorry for > sounding like a cargo cult follower, to have feature parity with Mac OS > X and Windows). And I also wanted to get a feel / help review the plugin > API before we freeze. I think that's a bad idea. And it eats the cdda:/ MRL space for GStreamer. _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
