Books/Accounting Periods proposal

Christopher Browne cbbrowne@localhost.brownes.org
Sat, 07 Apr 2001 14:54:32 -0500


On 07 Apr 2001 11:50:48 EDT, the world broke into rejoicing as
Derek Atkins <warlord@MIT.EDU>  said:
> I, too, like plan A.  However instead of thinking about files, I'd
> prefer if we did keep things in the abstract 'book'.  A book could
> be a file, it could be a database, it could be a remote database.
> You don't know, and you shouldn't care.  However, whatever we do
> should be something that is tied into the backend.  It would be nice
> if closing books might even be a backend function, rather than an
> engine function.  I'm not sure.

Yes, indeed.  This is indeed a _great_ way of "dispatching" into some
of the anticipated sorts of functionality, such as storing data in an
SQL DBMS.

Furthermore, it offers some really substantial enhancements by
allowing having multiple "data stores."  

Consider the following control file:

<?xml version="1.0"?>
<gnc>
  <datastore status="LOCAL" importance="MANDATORY">
    <location> 
      <format type="BERKELEY-DB"/>
	<file> /home/cbbrowne/financial/cbbrowne.db </file>
    </location>
  </datastore>
  <datastore status="BACKUP" importance="MANDATORY">
    <location> 
      <format type="XML"/>
	<file> /home/cbbrowne/financial/cbbrowne.xml </file>
    </location>
  </datastore>
  
  <datastore status="MASTER" importance="OPTIONAL" priority=1>
    <location> 
      <format type="CORBA"/>
      <iorlocation> /brownes/chvatal/master/financial/gnucash.ior </iorlocation>
      <authtoken> /home/cbbrowne/financial/cbbrowne.token </authtoken>
    </location>
  </datastore>
  
  <datastore status="MASTER" importance="OPTIONAL" priority=3>
    <location>
      <format type="POSTGRESQL"/>
      <host> chvatal.brownes.org </host>
      <port> postgres </port>
      <database> gnucash </database>
      <userid>cbbrowne</userid>
      <password>I was dumb and put secret info in this file</password>
    </location>
  </datastore>

  <datastore status="MASTER" importance="OPTIONAL" priority=2>
    <location>
      <format type="RPC"/>
      <host> chvatal.brownes.org </host>
      <port> postgres </port>
      <database> gnucash </database>
      <userid>cbbrowne</userid>
      <password>I was dumb and put it in this file</password>
    </location>
  </datastore>
  
  <datastore status="BACKUP" importance="OPTIONAL">
    <location> 
      <format type="XML"/>
      <file>/brownes/chvatal/backups/cbbrowne/finances/cbbrowne.xml</file>
    </location>
    <backupregime> /brownes/chvatal/backups/cbbrowne/finances/schedule.xml </backupregime>
  </datastore>
  
  <datastore status="BACKUP" importance="OPTIONAL">
    <location> 
      <format type="CORBA"/>
      <iorlocation> http://backups.gnumetric.com/backups.ior </iorlocation>
      <authtoken> /home/cbbrowne/financial/gnumetric.token </authtoken>
    </location>
    <backupregime> /home/cbbrowne/financial/gnumetric.backup </backupregime>
  </datastore>
  
  <datastore status="ARCHIVES" importance="OPTIONAL">
    <location>
      <format type="CDB"/>
	<file>/brownes/chvatal/backups/cbbrowne/finances/gnucash.cdb</file>
    </location>
    <archivalregime> /brownes/chvatal/backups/cbbrowne/finances/archival.xml </archivalregime>
  </datastore>
</gnc> 

Suppose, for a moment, that I have a laptop and a server, "chvatal."

Both of them have their own local directories,
/home/cbbrowne/financial, and an assortment of XML, token, and other
such files.

The above "control" file could be used on BOTH to control access to
the GnuCash "environment," with the following entertaining properties:

-> Supposing the laptop is on the local ethernet, it can get at both
   data on its own disk, and the "master" PostgreSQL version on
   chvatal.  It will seek to synchronize those; if I entered data on
   the laptop, offline, that gets pushed to PostgreSQL, and if data
   got entered on chvatal, the laptop can pull it over.

-> If the laptop is offline, at a "customer site," I can enter
   financial information, and it gets stored in the only data store
   present, /home/cbbrowne/financial/cbbrowne.xml.

-> Suppose I use the laptop to dial into the Internet.  It can head
   over to Gnumetric.com, grab an IOR, and push/pull data to the
   backup system there.

-> Chvatal periodically connects to the Internet, heads over to
   Gnumetric.com, grabs IOR, and does a backup, and can even pull back
   the data that the laptop pushed to Gnumetric.

-> Chvatal _primarily_ uses PostgreSQL as its data store, periodically
   does backups to an XML "archive."  Furthermore, it sometimes purges
   data, pushing that out to a CDB database where that may be
   retrieved if necessary.

-> Note that there's a choice of ways of getting at that "master" data
   store; you can try to get at the DBMS directly, or go via RPC, or
   via CORBA, depending on which is available, with priorities as
   noted.

All this certainly _won't_ get developed tomorrow.  Lots of "blue sky
dreaming" there, and more forms of data storage and interfacing than
anyone realistically wants to implement.  But having a couple or three
of the pieces is right well enough to justify having a "dispatcher"
that _could_ handle it all.  "Blue sky" opens it wide enough to
describe many of the sorts of extensions that might be nice someday.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.ntlug.org/~cbbrowne/resume.html
Coming  Soon  to a  Mainframe  Near  You!   MICROS~1 Windows  NT  6.0,
complete with VISUAL JCL...