From 2cdff16c92340b59f2c78073b933bee0b3b426a8 Mon Sep 17 00:00:00 2001 From: Linas Vepstas Date: Sun, 5 Apr 1998 10:49:16 +0000 Subject: [PATCH] notes about consistent updates git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@786 57a11ea4-9604-0410-9ed3-97b8803252fd --- src/engine/design.txt | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/src/engine/design.txt b/src/engine/design.txt index bb47b46ede..489fbf95d3 100644 --- a/src/engine/design.txt +++ b/src/engine/design.txt @@ -122,25 +122,30 @@ pthread_getspecific() to define a per-thread global and/or ring/queue. Engine Isolation ---------------- +Goals of engine isolation: + o Hide the engine behind and API so that multiple, plaggable engines + could be created, e.g. SQL or CORBA. + o Engine users are blocked from being able to put engine ineternal + structures in an inconsistent state. Updates are "atomic". + Some half-finished thoughts about the engine API: --- The engine structures should not be accessible to any code outside of the engine. - Thus, the engine structures have been moved to AccountP.h, TransactionP.h, etc. +-- The engine structures should not be accessible to any code outside + of the engine. Thus, the engine structures have been moved to + AccountP.h, TransactionP.h, etc. The *P.h files should not be included by code outside of the engine. --- The goal of hiding the engine internals behind an API is to allow the engine - to be replaced by a variety of back ends, e.g. an SQL and/or CORBA back-end. - -- The down-side of hiding is that it can hurt performance. Even trivial data accesses require a subroutine call. Maybe a smarter idea would be to leave the structures exposed, allow direct manipulation, and then "copy-in" and "copy-out" the structures into parallel structures when a hidden back end needs to be invoked. --- the upside of hiding behind an API is that the engine can be instrumented - with extension language (perl, scheme, tcl, python) hooks for pre/post processing - of the data. To further enable such hooks, we should probably surround all - operations on structures with "begin-edit" and "end-edit" calls. +-- the upside of hiding behind an API is that the engine can be + instrumented with extension language (perl, scheme, tcl, python) hooks + for pre/post processing of the data. To further enable such hooks, we + should probably surround all operations on structures with "begin-edit" + and "end-edit" calls. -- begin/end braces could potentially be useful for two-phase commit schemes. where "end-edit" is replaced by "commeit-edit" or "reject-edit".