exiting from gnome

[Derek Atkins]

Kevin,

Kevin Benton <kevinb at bentonfam.org> writes:

> So, If I understand this correctly, then I can't move to the PG backend
> yet because it doesn't support all my needs - scheduled transactions
> being one of the most important needs on my list...
> 
> I know that I may sound a bit like a thorn in the side, but I try to
> bring to the table a sense of how users who would be migrating from
> Quicken would expect things.  Derek - I agree that migrating to PG would
> be a good idea, but is it easy?  Does someone have to know how to manage
> PG to get it to work?  This is a valid concern for Quicken users who
> would consider migrating.  Also, how is the PG database backed up? 
> Quicken makes its backups nearly automatic and a non-issue.  A simple
> click on OK and your backup is made.

You need to already have PG running on your system.  This is as simple
as installing the postgres-server package on Red Hat.   Backups of the
PG database is out of scope.

> As we all know, there is a price for simplicity.  The question is, do we
> want to go that route?

Well, I've been arguing for an "embedded SQL" database since, oh,
gnucash 1.4.  This would give us the flexibility of a database and
real-time saves, but remove all the administrative tasks of running a
real database.  Externally it's just a single file which can be moved,
renamed, or backed up like any other data file.

The problem is that there is a large, highly vocal contingent who feel
that they absolutely must be able to load their data file in 'emacs'
and make changes.  I don't agree with their level of rabidity on the
topic, but then again I don't agree with the degree to which RMS
foams, either.

Do we want to go this route?  I believe whole-heartedly that we should
move from XML to 'embedded SQL' as the main data format.  XML should
be relegated to "data export" and "data import" for merging and
transmitting data.  But locally it should be in embedded SQL.

A better question is: will this happen?  With Matthew's new SQL work,
we should have MOST of the work done to actually have an extensible
SQL backend.  The only thing left would be the code hooks to use an
embedded SQL (e.g. MySQL Embedded Server) rather than Postgres.  My
hope is that Matthew can separate out the generic SQL from the
PG-specific SQL, so we can reuse as much as possible.  Still, I don't
know if this is where we will be for Gnucash-2.  I hope it is, but we
need developers with the time and capability to provide resources to
do the work.

-derek

> On Mon, 2003-03-10 at 10:15, TIm Wunder wrote:
> 
> > problem is... I'm a heavy user of Scheduled Transactions and there is no 
> > support in the Prostgres backend for SX's (yet). But, yes, I agree, the 
> > Postgres backend would be more appropriate for that kinda thing.
> > 
> > On 3/10/2003 12:06 PM, someone claiming to be Derek Atkins wrote:
> > > If you want this, use the Postgres backend.  That's what it's
> > > for.
> > > 
> > <snip desire to save users from themselves>
> > 
> > 
> > 
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at lists.gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> -- 
> Kevin Benton <kevinb at bentonfam.org>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

-- 
       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 at MIT.EDU                        PGP key available