On Sat, 30 Oct 1999, Kurt Granroth wrote:

> Michael J. Bedy wrote:
> 
> > Well, the GUI, reports and other stuff parts of the project could be
> > a "get-some-code-out-and-hack-on-it model," but the database should
> > be carefully designed to safe-guard the users data. I would prefer
> > that we followed a software engineering process for the whole thing,
> > but I know better then to expect something like that to happen
> > easily :-)
> 
> I *strongly* suggest you evalute using an existing database for the
> backend.  Databases of any sort can be veeery tricky and storing
> sensitive information will make it even tricker (as you well know).
> Going with a proven implementation would make your job a lot easier
> and a lot more worry-free.

   I agree. But I envision an abstraction that allows for a number of
different implementations. There would be an interface that rest of the
program could talk to, and each storage type would implement the required
features. 

   Also, it may be that the user wants a number of databases open
simultaniously (credit card, checking, etc.) and a way of organizeing this
is necessary.

   AND more than one part of the program may want to access the same
information at once (regeister is open, yet the report wants to read the
data also.) Coordinating this requires some thinking as well.

   BUT WAIT THERES MORE! The database layer should be as secure as
possible. This is probably a storage method specific problem, but we need
as part of our interface an abstraction for dealing with
encription/password type stuff.

   I need to type up the remainder of the notes that I had written down
this summer. I thought about all this stuff quite a bit, and I thought I
had a fairly good "database interface feature list" worked out. I will
post it when I have it done.

    - Mike



> -- 
> Kurt Granroth            | granroth@kde.org
> KDE Developer/Evangelist | http://www.pobox.com/~kurt_granroth
>         KDE -- Putting a Friendly Face on Linux
>