[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Addressbook Database
From:       Lars Doelle <lars.doelle () on-line ! de>
Date:       1999-04-07 23:05:00
[Download RAW message or body]

Peter Harvey wrote:

> > >
> > > How will it be installed without the user worrying about it? Will you
> > > choose a database to send with KDE? I for one will not us MySQL; I use
> > > PostgreSQL. Or will you rely on what the user has installed already?
> > > 90% don't install databases. Or will you let the user do all the work?
> > >
> >
> > I agree, trying to install xxSQL, ODBC and whatever else is needed would
> > be a pain. mySQL server + client ends up being over 4 megs in rpm format.
> > This is larger then kdebase! I rather not have to install a huge dtabase
> > on my system if I didn't have to, and I don't think we can expect a user
> > to do the same.

I agree also that to require having an SQL db installed is not a good idea
in the moment, though OS/2 bundled one with the OS and having it makes
sense in any commercial setup. To the contrary, having an ODBC infrastructure
integrated with kde is an absolute necessity.

> I have been putting off writing an ODBC Text File Driver for a while...
> partly because it is a pain. However, I have started working on just such a
> driver to address the concerns mentioned here. This would mean that a
> default ODBC driver could be included in KDE with very little fuss and very
> little overhead.
>
> This makes sense to me and I hope it makes sense to everyone here?
>
> The main problem with an ODBC Text File Driver is that it basically has to
> have a mini SQL engine in it. For example; is must parse and interpret
> incoming SQL commands and then execute the appropriate I/O functions. I am
> biting the bullet and looking into Lex/Yacc to help handling the SQL stuff.
> The rest of the stuff I have done before and should fall into place quickly.

Peter, there might be more efficient ways to do this.
I suggest to work on a generic server instead. All this
server needs to do is to pipe the queries via stdout to
a configurable program and to return the results.

Such a construction would for example allow to hook
a prolog or guile application in, which could be written
for such a purpose much more simply then a c program
since both languages are much better suited for symbol
processing, rewriting and planning anyway. A prolog
solution would take only a few hundred lines and one
would have a database that is ways stronger then any
sql dbms ever will become. And it would be text based
since both prolog and scheme repositories are text based
by their very nature.

If you would come up with such a generic server (or
a driver for it), i could add the parsing and db stuff
pretty quick.

This direction would have the additional advantage,
that it would mean to define a database indepent
_protocol_, fixing a huge disadvantage of the odbc
construction itself, that requieres a different driver
for every database though the whole construction
only requieres to have one if they would have made
a protocol instead.

Lars

[prev in list] [next in list] [prev in thread] [next in thread]