DB design document

Rob Browning rlb@cs.utexas.edu
17 Dec 2000 17:33:26 -0600


David Merrill <dmerrill@lupercalia.net> writes:


> >     * design an API that's exactly what we need, regardless of the DB
> >       involved, and plan to just have a server-side gnucash daemon
> >       that manages the DB interface, dealing with any limitations of
> >       the DB on the server-side before forwarding data back and forth
> >       -- for example, this means that you can pretend like you have a
> >       "rational" implementation.  It also means that you can have more
> >       flexibility in other areas because you can perform actions on
> >       the server side.  This approach, does, however, have plenty of
> >       drawbacks...
> 
> My thoughts, how they ramble...
> 
> I'm leaning toward using the approach of #3, to implement an API that
> could have any db engine behind it. Initially the db would be Postgres
> to avoid the difficulty of a db abstraction layer. A year from now I
> hope we will have more powerful db-agnostic layers available. We can
> revisit the topic then.

As you also suggest later in this message, the more I think about it
and read other people's comments, unless I'm overlooking something
obvious, having a gnc-server-proxy now seems to me inevitable.  It
provides us with a much stronger position.  We won't be tied to any
specific DB (eg. if the DB doesn't have rational numbers, we just
implement them in two columns and move some of whatever server-side
computation we need, if any, to the server-proxy).

We'll also have a lot more flexibility about how we handle
encryption/authentication.  On one end of the scale, for locations
where they know they have full-blown kerberos, or similar, we can let
them just turn off gnucash-specific encryption (and auth?), and on the
other end of the scale, for people who don't have an existing policy,
and don't want to have to re-work their network, we can handle the
issue ourselves -- managing the communication
encryption/authentication between the gnc-server-proxy and gnc-client
ourselves.

> That will be the nature of the first implementation. I always design
> way farther than I implement, so that when the later stuff gets
> implemented it has already been planned for. At some point probably
> weeks from now, I will put much more serious thought into drawing
> the line and deciding how much of the pie-in-the-sky will actually
> be in the 1.0 version.

Sounds good.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930