On Fri, 13 Aug 1999 18:04:23 PDT, the world broke into rejoicing as
Taral <[EMAIL PROTECTED]> said:
> On 13 Aug 1999, Rob Browning wrote:
>
> > We have support now for "transactions". Perhaps, we should make this
> > support stronger, perhaps add a feature that'll let GnuCash detect
> > lost transactions after a restart and offer to re-add them. Once
> > Christopher finishes the QIF import/text export (which will probably
> > supercede mine) mechanism, we could implement this pretty trivially by
> > spitting scheme forms to a log directory, one file per modification,
> > before we enter the data into the engine, then checking this directory
> > on startup for stragglers. If any are found, then we use the import
> > mechanism to suck them in. Files in this directory would be deleted
> > whenever a sucessful update was made. (This is just me thinking out
> > loud, so don't take it too seriously...)
>
> This is sounding _awfully_ like what SQL is for...
Let me be pedantic for a moment...
Precisely *what* about the above bears any resemblance to a Structured
Query Language?
That is, after all, what SQL stands for.
There may be merit to hooking in some known-to-be-pretty-reliable
embedded database system.
The above discussion of "transactions" suggests that there is merit to
looking into either:
a) A transaction processing monitor, or
b) Message queueing software that provides a logical equivalent.
None of the above implies a necessity for the bulk and complexity of a
fullscale relational database management system (ala PostgreSQL).
There are complaints that GnuCash has too many prerequisites now;
throwing in the need to set up a PostGreSQL database, with the associated
administrative overhead, packages, security, libraries, and probably other
things that are probably not coming to mind, is just Not A Good Move.
It would be fairly sensible to split GnuCash into a "server engine" and a
"display engine," and have these run in separate processes. Adding in
an ORB process, or a "message server," would be at the edges of "what
is sensible." Moving on to an RDBMS would be dramatic overkill for the
limited data requirements, and would add considerably to the complexity.
--
The light at the end of the tunnel may be an oncoming dragon.
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/tpmonitor.html>
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
