[ale] GnuCash (Was: Re: [OT] Home PBX?)

Derek Atkins warlord at MIT.EDU
Wed Aug 1 12:06:52 EDT 2012


Mike,

"mike at trausch.us" <mike at trausch.us> writes:

> On 07/31/2012 02:39 PM, Jim Lynch wrote:
>> I had to laugh at this response.  Many of you know that Derek has been 
>> involved in the gnucash project for a long time.  For some reason that's 
>> been lost to me in my advanced years, I had to compile gnucash from 
>> source once.   It is perhaps the most complex compile I've ever done 
>> with dozens of dependencies and requirements.
>
> Hey!  I love that program!  :-D

Thanks!  But I'm only one of many involved in the project (and honestly
at this point my only real involvement is maintaining a bunch of
gnucash.org servers in my basement and answering questions on the
mailing lists and IRC).  I don't do much coding there anymore.

[snip]
> That said, I really need to replace it with something a little less...
> single-user-ish.  I am using it only as a start for my business, until I
> have had the time to actually implement a system that is concurrently
> multiuser and Web-based.  Love it for things where I'm the only person
> ever likely to work on it at the same time.  Hate the fact that it
> doesn't do concurrent multiuser access, though, even on SQL databases...
> see http://is.gd/2GZ56H (GnuCash wiki) for why that is (at least for now...)

Getting concurrent multiuser access *IS* a goal.  However it's a long
ways off.  The reason is that GnuCash is NOT a DB App.  The internals
expect its data in core, not as lookups at every query.  Moreover, some
of the structure doesn't quite lend itself well to DB Schema (e.g. the
Key-Value-Pair Framework).  So in the case of concurrent users you have
a cache coherency problem to solve; you need to tell user A that its
data in core is invalid when user B makes a change.

The internals are moving toward being more DB friendly, but that's a
slow process, and will take time as developers have it.  It's not the
highest priority at the moment.

> If GC were to become a concurrent multiuser application, I'd probably
> simply write my other software to integrate with it, instead of
> reimplementing the things I need piecemeal, as time permits.
>
> I might even consider helping to add CMU access to GC, if the project
> has that as a goal at all (not sure about that even), if I manage to get
> to the point where I can stop to work on such a thing.  Though at the
> moment, that's a pretty big "if".

Patches are always welcome!  :)

> 	--- Mike

-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


More information about the Ale mailing list