Scope of GNUCash

Mike or Penny Novack stepbystepfarm at dialup4less.com
Wed Feb 14 09:35:38 EST 2018


On 2/13/2018 4:53 PM, Matt Graham wrote:
> 😊 I think I would love to sit down in a pub with the three of you (Wm, Adrien, and Mike). I think we could have such awesome semi-drunken discussions about the nature of life, the universe and everything!
>
> I think you have basically answered my question, and I think we all basically agree on the rough direction things *should* go in (separate interacting packages). I’m just not sure how to help make it happen (I’m an enthusiastic amateur when it comes to programming). I think I’ll start by updating the budget part of the tuts and concept guide like I have promised elsewhere, and then start looking into how the C++ modules have been structured (to see what connection will be possible within the 3.0 releases).
>
> Thanks and regards,
  Well of course I am not an amateur, it is how I used to make my 
living. But I can't help out with program design/coding unless/until I 
can get bandwidth here a home < unwilling to cut down enough large trees 
to get a "window" for satellite >

But besides being a senior systems analyst (programs) also a senior 
analyst (business -- the part that comes before)

A comment on the third part --- HOW the process of feeds and their 
reception is handled. That  can be deferred for now and at the 
beginning  can assume manual because whether "job scheduling" is 
possible is more or less OS dependent. For example, I haven't a clue how 
for Windows could have a job submit (other jobs), tell whether other 
jobs were running or had completed and if so, whether successfully, etc. 
That I knew very well how to do this under MVS/XA (a mainframe OS) and 
am pretty sure I could figure it out for a 'nix is besides the point.

Remember (an important point) a feed can FAIL. Not only once the program 
tries to bring it in but it could have failed in "input editing". In the 
initial project phase we might better assume that a human is running 
these things and will not start the next step of the process until 
seeing that predecessor steps worked. How an automated system is stopped 
part way and resumed after a "fix" is a project in itself. I'm the sort 
of guy who used to get woken up in the middle of the night when the 
programmers on standby couldn't fix the problem.

Michael


More information about the gnucash-devel mailing list