How hard would a "no global server" version be?
(Please cc: me in any replies. I'm not on the mailing list ATM, but
I'd be happy to subscribe if that's preferred or if this turns out to
be worth pursuing.)
We've been toying with switching to using SQL for the financial engine
in GnuCash for a while, and eventually we'll almost certainly add
support for an SQL backend as an option, but we haven't gone that
route yet because for individuals using the program (i.e. people who
just want something like Quicken/MSmoney/etc.), we don't feel it's
reasonable to require them to handle installing and maintaining an SQL
server just to do their checkbook.
However, if, for the single users, we could find an SQL system that
would (like sleepcat) allow us to keep the database in a local file,
and not run a global server[1]If a one-process solution would be too hard, we'd probably be fine with hacks like just automatically launching the server as the user whenever the user launches the app, and then having that dedicated server talk to the app exclusively via FS sockets or whatever, and manage its database in one of the user's directories., we'd be set. We could use that for
single-users and then support maxsql/postgresql for users who
want/need more power.
[1]: If a one-process solution would be too hard, we'd probably be fine with hacks like just automatically launching the server as the user whenever the user launches the app, and then having that dedicated server talk to the app exclusively via FS sockets or whatever, and manage its database in one of the user's directories.
with hacks like just automatically launching the server as the
user whenever the user launches the app, and then having that
dedicated server talk to the app exclusively via FS sockets or
whatever, and manage its database in one of the user's
directories.
So what I'd like to ask is this:
(1) Are there any plans to add anything like this?
(2) How hard do you think it would be for an outsider to add this
feature as an option, and if someone did, would you be likely to
be interested in incorporating the result upstream?
Thanks
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
<rlb@debian.org> <rlb@gnumatic.com> <rlb@gnucash.org>
So what I'd like to ask is this:
(1) Are there any plans to add anything like this?
Not specifically. Postgres is a full-up database, and afaik there isn't
a contingent of our developer community which is sufficiently interested
to pursue "mini" configurations. But...
(2) How hard do you think it would be for an outsider to add this
feature as an option, and if someone did, would you be likely to
be interested in incorporating the result upstream?
in the environments I'm familiar with (e.g. RH/Mandrake with PostgreSQL
and Gnome), it would be pretty easy to wrap the Postgres libraries and
backend to be a "standalone server" application. When you start a
"postmaster", you can specify the listener port number, database
location, etc, and on specific systems you could easily have a scripted
startup/installation procedure which gets things set up.
Of course we'd prefer that people realize that everything in the world
would be better if they just had a Postgres server running 24x7 ;)
- Thomas
On Tue, 29 Aug 2000, Thomas Lockhart wrote:
So what I'd like to ask is this:
(1) Are there any plans to add anything like this?Not specifically. Postgres is a full-up database, and afaik there isn't
a contingent of our developer community which is sufficiently interested
to pursue "mini" configurations. But...(2) How hard do you think it would be for an outsider to add this
feature as an option, and if someone did, would you be likely to
be interested in incorporating the result upstream?in the environments I'm familiar with (e.g. RH/Mandrake with PostgreSQL
and Gnome), it would be pretty easy to wrap the Postgres libraries and
backend to be a "standalone server" application. When you start a
"postmaster", you can specify the listener port number, database
location, etc, and on specific systems you could easily have a scripted
startup/installation procedure which gets things set up.
could they, from within the program itself, just do:
postgres -D <datadir> <database>
at the start, and kill that process when the program finishes?
similar to what we do in initdb to initialize the database itself?
basically, the 'install procedure' for GnuCash would be something like:
/usr/local/pgsql/bin/initdb --pglib=<pglib> --pgdata=<mydir>/.data
echo "create database gnucash" | postgres -D <mydir>/.data template1
and then when you run gnucash, you would start up the postgres daemon as:
/usr/local/pgsql/bin/postmaster -p <randomport> -D <mydir>/.data
where randomport is set as part of the install process?
Alfred Perlstein <bright@wintelcom.net> writes:
I think all of this is completely do-able with a few small hacks on
the application's side. First off you can invoke postgresql with
a -D option (where the data is) that points to some subdir in the
user's homedirectory. The only real problem that I see that there
doesn't seem to be a way to specify the path to unix domain socket
that postgresql uses, but that shouldn't be too difficult to fix
probably no more than an hour of coding or so.
Hmm. Actually, if this really is feasable, and if we decide this is
the way we'd like to go, I'd be happy to spend quite a few hours
making this work right, documenting it, etc.
Looks like I'll have to do some poking around and talk to some of the
other gnucash developers. Spending time on postgresql might be a much
better investment than spending time on the libxml output/input format
I was about to begin.
Thanks so much.
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
Import Notes
Reply to msg id not found: AlfredPerlsteinsmessageofMon28Aug2000182126-0700
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Not specifically. Postgres is a full-up database, and afaik there isn't
a contingent of our developer community which is sufficiently interested
to pursue "mini" configurations. But...
Well perhaps I'll become that contingent :>
Of course we'd prefer that people realize that everything in the
world would be better if they just had a Postgres server running
24x7 ;)
No doubt, but perhaps the "mini" configuration might be an insidious
method of initiating the corruption leading to the "one true way".
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
Import Notes
Reply to msg id not found: ThomasLockhartsmessageofTue29Aug2000042302+0000
could they, from within the program itself, just do:
...
Right, something like that should work just fine.
- Thomas
On Tue, Aug 29, 2000 at 12:25:08AM -0500, Rob Browning wrote:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Not specifically. Postgres is a full-up database, and afaik there isn't
a contingent of our developer community which is sufficiently interested
to pursue "mini" configurations. But...Well perhaps I'll become that contingent :>
Another use for such a mini config would be the PDA market. IBM's got
DB2 for the Palm, if I remember correctly. That's a little _too_ small a
target, I think, but the new crop of PocketPC devices have enough memory
and horsepower to be useful with a real database.
Of course we'd prefer that people realize that everything in the
world would be better if they just had a Postgres server running
24x7 ;)
Naw, that'd suck all the joules out of my battery!
No doubt, but perhaps the "mini" configuration might be an insidious
method of initiating the corruption leading to the "one true way".
With the PDA, we'd need a conduit to go back and forth to the desktop,
which runs the 24x7 full server. Corruption by another path...
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005