[SQL-Ledger-users] OT: Web-based Checking Software

Linas Vepstas sql-ledger-users@lists.sourceforge.net
Fri, 4 May 2001 12:03:56 -0500


--xgyAXRrhYN0wYx8y
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 03, 2001 at 09:22:01PM -0500, cbbrowne@hex.net was heard to rem=
ark:
> On Thu, 03 May 2001 20:19:27 CDT, the world broke into rejoicing as
> linas@linas.org (Linas Vepstas)  said:
> > List-Archive: <http://lists.sourceforge.net/archives//sql-ledger-users/>
> >=20
> > On Thu, May 03, 2001 at 04:37:12PM -0700, Roderick A. Anderson was hear=
d to=3D
> >  remark:
> > > Slightly off topic but I'm looking for check book software.  I'm
> > > currently using GnuCash which is nice but I haven't found a reasonable
> > > way to tie into SQL-Ledger.  So I'm hoping someone knows of some
> > > web-based software.  Probably, needless to say, but perl based, and
> > > using PostgreSQL (or other DBI based method) it preferred.
> >=20
> > If anyone can help the gnucash developers in figuring out how to tie
> > into sql-ledger (and/or writing the code to do the same) that would be
> > great.   BTW, gnucash has a a beta postgres backend.  It works fine in=
=3D20
> > single-user mode, but has difficulties in multi-user mode.
> >=20
> > If you do debate this further, please cc. the gnucash-devel@gnucash.org
> > mailing list.
>=20
> I've been trying out SQL-Ledger recently.  [Aside: Looking at doin'
> some writing for fun and profit.]
>=20
> Pretty slick.  Simple, but slick.
>=20
> The problem with interfacing GnuCash with SQL-Ledger will be that
> they've got quite _vastly_ different data models.  The GnuCash tables
> tie together via GUIDs, whilst SQL-Ledger ties together data in A/R,
> A/P, Inventory, and G/L.  While SQL-Ledger has a somewhat more
> sophisticated set of journals, the data _in_ the tables for GnuCash
> looks a lot fancier, particularly in terms of commodity handling.

gnucash unifies g/l and inventory into one.  I should study up
on the sql-ledger data strucutres a bit, though ...

> One thing that SQL-Ledger "buys" is that it basically does database
> queries on demand; _no_ need for the "event notification" that makes
> the GnuCash Register a fairly hairy chunk of code.  That is, if you
> make a change to a bit of data, the view of the register doesn't
> automagically get updated.  And you don't get to see more than one
> transaction's data at a time.

This is a classic example of the difference between distributed and=20
centralized apps. SQL-ledger is centralized, thus making things easy.
(the web browser is used as a slightly prettier version of a dumb
mainframe-attached green-weenie terminal.  It has the same performance
charateristics, and the same limitations on how data can be manipulated
and displayed as any mainframe based software.  The more things
change...)

Gnucash could do a similar stunt with a little bit of clever X11
protocol forwarding.   Say I ran one instance of gnucash on a server
somewhere. Then with some X11-magic, I could make it "multi-user"
by having it display some windows on one users remote desktop, and other
windows on another remote desktop.   Because its only X11 traffic that
is getting distributed, most of the 'hairy' issues are handled entirely
within the single instance of gnucash, thus making the difficult
distributed problems 'go away'.

Taking the distributed computing 'high-road' is hard.  Maybe folly?
Maybe we should focus on getting a multi-X11 connection stunt actually
usable?  That way, it could display on mswin desktops as well...

> That difference has the "negative" implication that SQL-Ledger doesn't
> provide "friendly, dynamic" views.  You only get to closely look at
> one transaction at a time, and if you fiddle the date, the transaction
> doesn't "magically" move to another spot on the screen, and balances
> don't change.

So gnucash is glitzier.  Functional purists don't need glitziness.=20
But the general computing public has clearly voted for style ovr
substance ...=20

> On the other hand, there's not the complex register code.  It's pretty
> easy to write an HTML screen to edit one transaction at a time.
> Furthermore, there's the merit that SQL-Ledger is a _LOT_ easier to
> make play well as a multi-user application, because there's no vast
> interlocking set of event notifications to worry about.

Nahh, that's not that hard. I can make it work.  Its' the running
balances (as explained in other note) that are giving me heartburn.

--linas

> --
> (reverse (concatenate 'string "gro.mca@" "enworbbc"))
> http://vip.hyperusa.com/~cbbrowne/resume.html
> Rules of  the Evil  Overlord #148. "Before  ridiculing my  enemies for
> wasting time  on a device  to stop me  that couldn't possibly  work, I
> will first acquire a copy of the schematics and make sure that in fact
> it couldn't possibly work."  <http://www.eviloverlord.com/>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

--=20
Linas Vepstas -- linas@gnumatic.com -- http://www.gnumatic.com/

--xgyAXRrhYN0wYx8y
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE68uD7ZKmaggEEWTMRAjH/AJ4/7uJ1kbmausSBemycLVddIgZ+5gCdHIh5
BraOuvm/KIXlcvG9IFBoJU8=
=MfJl
-----END PGP SIGNATURE-----

--xgyAXRrhYN0wYx8y--