GC architecture for backends

[Phil Longstaff]

On Thu, 2006-02-11 at 08:40 -0600, Daniel Espinosa wrote:
> 2006/11/1, Derek Atkins <warlord at mit.edu>:
> > Quoting Daniel Espinosa <esodan at gmail.com>:
> >
> > >> Also, we'll need to make changes to handle the fact that file://
> > >> should get redirected to sqlite:// -- but the code will need to
> > >> test the file first to see what kind of file it is, so that File -> Open
> > >> does the "right thing".   I.e., the fact that we're using SQLite
> > >> should get hidden from the user when we migrate to it.
> > >>
> > >
> > > I think the URI mus be gda:// or db://, think that gda is wrapper for
> > > many DB backends not just sqlite.
> >
> > At some level we need to be able to specify what kind of database is
> > sitting behind there.  At SOME point we need to know how to specify
> > a filename for SQLite vs. a host/port/user/password for PG.  So clearly
> > there's some differentiation there.
> >
> 
> Isn't the case for GDA, when you create a DSN, you can use this name
> to connect: you just need to specify the DSN, user, password and some
> options (read only for example) see the libgda.h file where you'll
> find some convenient functions to easy use GDA and quick do some very
> common task.
> 
> > But this is irrelevant to what I meant.   What the user types into the
> > File->Open dialog does not need to be the string that gets passed the GDA.
> 
> If you have an option to connect or open a DSN the URI could be:
> 
> gda://gnucash:username:password
> 
> With a gnomedb-login widget you can select a predefined DNS, get
> username and password, and thats all you can pass it to the QOF beggin
> session function to open the back end.
> 
> 
> > I'm just pointing out that we need to intercept that input and handle
> > it appropriately, which may mean adjusting the actual string and perhaps
> > calling the XML or GDA-with-SQLite backends.
> >
> 
> In the event that GC will use just SQLite or other DB engines, you
> don't need a special intercept, I think the dialog *must* allways show
> a gnomedb-login widget to select the DSN, write a user and a password,
>  and Go!
> 

I haven't thought through all of the issues around connections, but I
don't think we want to use predefined DSNs.  A user shouldn't have to
set up the GC DSN with an external tool in order to use that DSN within
gnucash.

Phil