Access Controls

[David Merrill]

On Fri, Dec 29, 2000 at 02:46:51AM -0600, linas@linas.org wrote:
> It's been rumoured that cbbrowne@ntlug.org 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                dmerrill@lupercalia.net
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.