The GnuCash core

[Josh Sled]

On Mon, 2004-12-06 at 15:28, Paul Dunbar wrote:

> Well there are a few reasons I'm going for something web-based.
> 
> I want to provide a personal finance management system to the small
> number of users of my website, mostly for myself, but people have
> seemed interested in this idea when I talk about it.  In that sense my
> target audience isn't so much end users as it is web administrators
> who would be interested in providing PFM features to their users (I've
> seen finance.yahoo.com and heard of MSN providing something like this,
> though not to a full extent).  

Well, to be clear: GnuCash is a single-user application right now, so
depending on what types of features you want to offer there might be
some more work attached.

> I want something that runs commands on
> a schedule (like bill payments, alerts, importing bank transactions,
> reconciling, etc.), and it seems to makes sense to use a server for
> this since a server is supposed to be always on.  

Note that  Scheduled Transactions _only_ supports Transactions ... not
imports, reconciliation, "alerts", or anything else.

At the same time, it would be useful to factor the "Scheduled" aspect
out from the "Transaction" aspect [or any other system-actor], however. 
So not only is there the refactoring, but also the adapters between the
scheduling core and those other subsystems.  As well, in order to allow
those features to run in a scheduled/unattended manner, there's probably
a whole "task+params" subsystem, too...

> I also want this for
> platform independance, I would like to login to an SSL site and input
> transactions, check balances, etc. without going through the trouble
> of X11 forwarding or transferring data. 

Yeah, web apps do indeed rock. :)

> If I do decide to use the gnc api for this,  I plan to do my own UI
> stuff, as well as reports and things like scheduled tasks (All though
> I might try to see if I can't marry my idea of using cron with gnc's
> scheduled payments system).

Well, I hope and believe that if you're going to go forward and want to
leverage GnuCash, that there can be some mutually beneficial overlap in
the work.  For instance, it would probably be more time-efficient to 
factor the non-UI "business logic" out from the UI-servicing components
into a layer on top of the engine, rather than have a web-based
front-end re-create the _entire_ UI.

Plus, the existing reporting code _already_ generates and renders HTML,
so it makes much more sense to simply have that generate better HTML
[and better-handle charts, &c.] than re-create the reporting subsystem.

> btw I appreciate you not insulting/shooting me down on this though, I
> know it seems a little impractical and a LOT ambitious, but I think
> with proper watering and plenty of sunlight, this could be really
> useful. :)  I haven't been doing development for longer than a couple
> of years, but I think I can put something decent together IF I use the
> right design and have useful criticism.

Not impractical at all, though there is a lot of work there.

A web-based front-end to gnucash has been desired for quite a while; in
fact, one of the original design ideas was as a web-based front end.  

Practically, however, there is a lot of effort that has been spent
creating the desktop-environment user interface widgets that make
financial-data-entry work really well.  These days it wouldn't be
impossible to recreate work-alike widgets in javascript, and leverage
some of the nicer script-accessible features [the XmlHttpRequest object,
for instance] available in modern browsers to have a dynamic web
front-end to GnuCash's core.

I would hope that that front-end could sit beside a traditional and
desktop-native front-end, on top of the same engine.  It'll take some
coordination to get there, but it's worthwhile.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`