Transaction Engine

[Derek Atkins]

Christopher Browne <cbbrowne@smtp.hex.net> writes:

> Notably:
> a) Balance management [the thing of keeping track of daily balances,
>    or perhaps based on some other granularity];

I think part of the proposal was to checkpoint the balances within the
database.  Then the UI can compute running balances from the last
checkpoint.  Granted, this requires the UI to grab all the
transactions since the last checkpoint, which may or may not be an
onerous task.  So, it is unclear if the gnc_server would actually
handle this task.

> b) Event management; telling GUIs when [say] a balance on which the
>    present screen depends, or when one of the transactions on screen
>    have changed.

Well, yes, this is certainly "outside" to DB.  I was considering this
part of the role of the gnc_server, to send client notification events
when data changes.

> But the DB won't be managing all aspects of balances and events.
> That needs to be handled by what seems best termed as a "transaction
> manager;" I'm not speaking of commit/rollback, but rather of having
> a server program that manages the Stuff That Happens when you update
> a transaction.  Two things would include:
>  - Updating balances
>  - Notifying any bits of the system that need to know when a particular
>    transaction is updated.  Such as letting the GUI know to display new
>    values.

Well, the gnc_server would notify the gnc_client that data changed,
and the gnc_client would notify the UI.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available