Subject: Re: [linux-audio-dev] (no subject)
From: .n++k (Knos_AT_free.fr)
Date: Tue Jul 23 2002 - 13:11:23 EEST
From: rm <async_AT_cc.gatech.edu>
Subject: Re: [linux-audio-dev] (no subject)
Date: Tue, 23 Jul 2002 05:33:56 -0400
Message-ID: <20020723053354.H582@tokyo.cc.gatech.edu>
async> On Tue, Jul 23, 2002 at 10:45:55AM +0200, .n++k wrote:
async> > | > > Why not use an SQL database for storing session/project metadata?
async> > | > > (configuration and such) We have the benefit of having a few quite
async> > | > > stable free software SQL databases. (mysql, postgresql, sapdb) so
async> > | > > requiring one wouldn't be too much to ask.
async> >
async> > Well it would be just as easy to me to have a small util with a dump
async> > of the database.. as would any other manipulation/analysis on the
async> > projects data be. Backup are easy too.
async>
async> requiring an sql db for this sort of thing would be gratuitous. for
async> one, it's another dependency that people would have to download,
async> compile, and setup. for most databases, the setup is non-trivial. (i
async> can't run my audio app, because i can't figure out how to setup my
async> database?)
That would be an amazingly bad design if the db persistence was a
requirement for starting/using the apps. I just think the cost of
having a dbms on a desktop linux machine to be really low. We all have
a different linux experience, which is part of the fun of it.
But aren't musicians a different kind of users than desktop users?
async> secondly, it's unnecessary as i understand the requirements
async> of task. you might be able to justify a smaller database like
async> sleepycat's stuff, but files are more reasonable and pretty much
async> everyone has a filesystem these days. you just don't need the majority
async> of the features that a relational db provides.
I said sql dbms, pointing at the fact it would be the simplest of that
family of databases. (like that primitive mysql is.. but nobody would
be forbidden to upgrade to a real relational one)
Well i don't see it as unnecessary, just for the reason that you NEED
a database. so any objection is either a practical one or a theorical
one. Maybe the hidden objection is that it's too complicated for an
application writer to relationalize his application's data
model.. Myself i find it difficult to xml-ize data sometimes just for
the fact that it freezes a certain hierarchy.
async>
async> gconf2 might be an appropriate model to look at for ideas. api calls
async> for accessing the information are defined, and the backend is left
async> unspecified (but likely fs based initially). additionally, swig,
async> corba, etc can be used to provide bindings of the api to most
async> languages.
My preference probably comes from the fact i far prefer to install a
rather stable (api wise) database server (1 software) than to have to
install dozens of gnome packages..
Anyway, as a summary, what is the be solved:
. defining, naming, identifying a session (= project)
. communicating with the apps to request loading and saving
session associated data.
. 1. each app is passed enough knowledge to store their state themselves
or
2. an api and library is designed that can abstract finding the location
of the project itself, how to store the data etc..
I fear that 2. would be a complete reinvention of things that have been done many times before (dbms) and thus would either result in:
. not being done
. being done, incompletly
I'd prefer 1. although it freezes the backend.
..
This archive was generated by hypermail 2b28 : Tue Jul 23 2002 - 13:28:48 EEST