Thread: How hard would a "no global server" version be?
(Please cc: me in any replies. I'm not on the mailing list ATM, butI'd be happy to subscribe if that's preferred or if thisturns out tobe 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], 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 theserver as the user whenever the user launches the app, and then having that dedicated server talk to the app exclusivelyvia 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 yoube 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?
> could they, from within the program itself, just do:
...
Right, something like that should work just fine.
- Thomas
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
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
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