> >
> > I am suggesting that unixODBC be used for the back end access to a database (
> > http://www.genix.net/unixODBC ). Any thoughts on this?
>
> I would suggest to use some sort of abstraction layer in between for everything
> that does not directly depend on having a database below.
>
> For the addressbook interface for example, there are several approaches
> possible (database, file, LDAP, ...) that should all be available without extra
> effort for the application programmer.
>
> If I understand current development paths right, we may now use loading
> shared libs/objects on demand -- other Kde apps / components do it already.
> This allows very flexible and elegant dynamic loading of drivers.
>

Hmmmm... Ok... well why not make ODBC that interface. It already has;

1. a Driver Manager
2. a well documented spec
3. a widely used/portable spec
4. C++ wrappers
5. many Drivers including SQL Servers and a text file driver (but not LDAP yet?)

What do you think?

Peter

BTW: I created the unixODBC Text File Driver to address concerns about having to
install a SQL Server. The Text File driver is good enough for a proof of concept
and could be polished to be 'poduction' quality in short order. I created most of
unixODBC and I would be willing to help any KDE app developer get their app up to
speed with ODBC whereever it makes sense.