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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
