sqlite file format, anyone?

[Derek Atkins]

Christopher Browne <gnucash at cbbrowne.com> writes:

> It seems no more reasonable to expect that casual home users have to:
> 
>  - Run mke2fs, or whatever else is involved in setting up filesystems;
>  - Run whatever frightening incantations are involved in getting X
>    working.

If this is how you feel then you are grossly over-estimating the
competence and skillset of the average user.  Most users grab the Red
Hat install media and click "go".  They have no clue what mke2fs is.
They have no clue how to set up X.

> And the notion that PostgreSQL doesn't have an "embedded server" is just
> not true, unless you're hung up on trying to force there to be just one
> OS process.

Indeed, I am.  Another process means another thing to crash, and
another service to operate.  My parents can barely login to their
computer, let alone administer a postgres DB.  Also, I come from an
environment where people don't own their machines.  They use public
cluster machines with a distributed file system.  The average user
cannot start any process that needs root access; all processes are
owned by them.  Starting a postgres server in this environment
is... challenging.  However an embedded server would work just fine,
because is runs within the application in the user's context.

> mkdir("~/GnuCash/DB");
> system("initdb -d ~/GnuCash/DB");
> [dribble a few changes into ~/GnuCash/DB/{pg_hba|postgres}.conf,
>    notably turning on TCP/IP, picking a port #, probably not too 
>    much else...]
> system("pg_ctl -D ~/GnuCash/DB start");

Well, this isn't very portable.

> That may require having multiple processes around, but I absolutely
> reject that this represents any sort of "problem" worthy of "solving."
> Linux is a Unix-like system, and does a perfectly good job of managing
> any reasonable number of concurrent processes, and even quite
> _un_reasonable numbers thereof.

Well, you're welcome to reject whatever you want.  IMHO replacing the
XML file with a DB file is a worthy goal.  Having the data file remain
a single file is also a worthy goal.  You may disagree with those
goals, but then again you're not an implementor (anymore).

> I seriously doubt that any "embedded DBMS" would offer anything that
> would _truly_ be smaller or simpler to work with.

Simpler from who's standpoint?  I'm looking at it from a user's
standpoint.  You clearly are not (or you are grossly exagerating the
abilities of the average user).

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