On Mon, 2004-02-16 at 10:31, Andreas Bombe wrote: > Which is just a strong hint that using an XML backend (or any other > non-random access backend) is wholly inadequate, not that syncing the > library instantly is not the very right thing to do. They're related, sure. But we were talking about the current backend. > What would speak against a gdbm backend, apart from the additional > library dependency? Nothing, it's definitely possible. Experiments with how gdbm performs would be a good idea. If we're going to do major work on the backend though, I'd like to take a closer look at sqlite. > This solution would be rather XML (or generally non-random access > backend) specific. Probably we should stop using XML as the working > database backend and demote it to an export database that is dumped on > shutdown only. I'm not sure I understand what you're saying - we would write to *both* a gdbm file and XML? That seems a little crack. If we're going to switch to a new backend, we should just switch. > That way we'd have an up-to-date template to initialize newly > implemented backends. If we have gdbm and someone implements SQL, the > SQL Rhythmbox wouldn't have to have gdbm compiled in to initialize the > SQL database, for example. No hassles with data conversions on upgrades > and downgrades that way. Supporting upgrades from XML or gdm to sqlite shouldn't be hard. Downgrades are problematic, and I don't see a big need to support that.
This is a digitally signed message part