On Fri, Dec 29, 2000 at 02:46:51AM -0600, [EMAIL PROTECTED] wrote:
> It's been rumoured that [EMAIL PROTECTED] said:
> >
> > It should be clear why Transaction engine and DB engine should stay close;
> > they will need to communicate quite a lot of data in order to negotiate
> > the parts that are to be submitted to the GUI. A "for instance" would
> > be that if the DB does not support computing sums/balances internally,
> > the transaction engine will need to do so, and will have to talk heavily
> > with DB.
>
> I had always hoped/envisioned that the engine could run both in the server
> *and* the client. In the client, it provides a convenient programming
> API, and a data cache. In the server, it provides transactional
> capabilities & functions (and a convenient programng API).
What exactly is this "transaction engine"? All transactions can be
handled, and should be handled, within the db itself. The engine will
need to be aware of this functionality, but it needn't do anything to
make it happen. Any other approach is a mistake and a recipe for
disaster.
--
Dr. David C. Merrill http://www.lupercalia.net
Linux Documentation Project [EMAIL PROTECTED]
Collection Editor & Coordinator http://www.linuxdoc.org
Finger me for my public key
We are the flow, and we are the ebb.
We are the weavers, we are the web.
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
