From 87f1d9c4f0b2c9c23ca0d1ffa398643c202b784d Mon Sep 17 00:00:00 2001 From: Dave Peticolas Date: Fri, 21 Apr 2000 18:21:50 +0000 Subject: [PATCH] *** empty log message *** git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@2193 57a11ea4-9604-0410-9ed3-97b8803252fd --- src/engine/design.txt | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/src/engine/design.txt b/src/engine/design.txt index 5ecfc55caa..ad6a83a115 100644 --- a/src/engine/design.txt +++ b/src/engine/design.txt @@ -35,7 +35,7 @@ the user. Note that the sum of the values of the splits is always computed with respect to a currency; thus splits can be balanced even when they are in different currencies, as long as they share a common currency. The conversion price -is simply the rpice stored in the split. This feature allows currency-trading +is simply the price stored in the split. This feature allows currency-trading accounts to be established. Every split must point at its parent transaction, and that transaction @@ -157,7 +157,7 @@ many ways can be better to the later design. errors. For example, it can be used to implement a trace mechanism. (3) (with the right implementation) Can be thread safe. (4) Allows errors that occurred deep in the implementation to be reported - up to much higher levels without requireing bagagge inthe middle. + up to much higher levels without requiring baggage in the middle. The right implementation for (2) is to implement not a single variable, but a stack or a ring (circular queue) on which error codes are placed, and from which error @@ -168,9 +168,9 @@ 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 + o Hide the engine behind an API so that multiple, pluggable engines could be created, e.g. SQL or CORBA. - o Engine users are blocked from being able to put engine ineternal + o Engine users are blocked from being able to put engine internal structures in an inconsistent state. Updates are "atomic". Some half-finished thoughts about the engine API: @@ -193,7 +193,7 @@ Some half-finished thoughts about the engine API: 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". + where "end-edit" is replaced by "commit-edit" or "reject-edit". Reconciliation @@ -224,14 +224,14 @@ How about the following proposal: -- transactions marked 'y' (reconciled) in gui cannot be edited. -- gui will allow 'y' to be changed back to 'n' or 'c' (thus allowing editing). --- engine will also enforce above restricitions +-- engine will also enforce above restrictions -- transactions marked 'f' cannot be changed, period, either in the gui or the engine. Let me know if this is a bad idea, otherwise I'll implement it. Should I change the font or color or something for reconciled -transctions, to provide some (strronger) visual cue? If so, what +transactions, to provide some (stronger) visual cue? If so, what color/font/whatever? @@ -317,16 +317,16 @@ horrible things happen to the "master" database file. Session Mgmt ------------ -To allow the user of the engine some guarentee of atomic updates, +To allow the user of the engine some guarantee of atomic updates, serialized file I/O, related miscellany, the concept of a session is supported. No file IO can be performed until a session has -been created, and file updates are not guarenteed atomic unless +been created, and file updates are not guaranteed atomic unless performed within a SessionBegin/SessionEnd pair. Note that (in the current implementation) data can be manipulated outside of the session; its just that it cannot be saved/made persistent. -The goal of sessin management is to ensure that e.g. two users don't end +The goal of session management is to ensure that e.g. two users don't end up editing the same file at the same time, or, e.g. that an automatic stock-quote update daemon running under a different pid doesn't trash data being currently edited by the user. @@ -344,7 +344,7 @@ Ideas for engine enhancements: write, and compare the two resulting AccountGroups for equality. During development, this is a good idea, as it will help uncover - thinko's more quickly, instead of letting them hid for weeks or months + thinko's more quickly, instead of letting them hide for weeks or months (as the last one did). Its not a bad self-consistency check when monkeying with the internals, damn the performance. @@ -352,3 +352,4 @@ Ideas for engine enhancements: September 1998 +