Engine, Inventory, Payroll, etc

[Conrad Canterford]

Hi all,
I've now got the situation where I really need to think about
implementing some serious inventory stuff, and would find payroll really
useful as well. I was thinking about how this would be best implemented,
and I have come to some conclusions and suggestions which I'd like to
pass by people for comment. It is nothing dramatic, but I think it
should be clarified now, before too much development happens based on
wrong assumptions.

There is an implication in the doco that the (current :-)) plan is to
implement all the "business" functions as part of the one "gnucash"
application. Having become extremely proficient at cursing and swearing
at StarOffice for its memory (and processor) footprint, can I suggest
that this is a Bad Plan (especially for those that don't require this
extra functionality).
Since the plan already entails a separation of the GUI and engine, I'd
propose that the better solution is to clearly and explicitly publish
the "correct"/"supported" interfaces to the engine, and leave such
stand-alone applications out of the picture, so-to-speak.
An inventory control program would only need to appear to the GnuCash
engine as (effectively) another GUI. Similarly for a Payroll
application. This leaves the way open for other people to produce
specific applications for their purposes, but still have them interface
with the main engine. For that matter, it would allow someone to develop
a M$ Windoze GUI that can talk to the engine, for those big corporates
that still believe in spending too much money on useless software, and
not enough on the real software. 
It would not need to be a separate interface for each type either - the
same sort of things that get done by the GUI now would be what you'd be
sending to GnuCash anyway. One general engine interface, and people can
develop their own add-ons as required (inventory, payroll, job costing,
accounts receivable/payable, etc).
This would mean that the inventory, payroll, etc. applications could
then be "spun off" as separate development efforts.

Any thoughts, comments, or gaping holes you see in my logic?

Conrad.
-- 
Conrad Canterford (conrad@mail.watersprite.com.au)
Water Sprite Pty Ltd   | info@mail.watersprite.com.au
 GPO Box 355,          | Incorporating:
 Canberra, ACT, 2601   |   Australian Tour and Event Management (ATEM)
 Australia.            |   Ticketing Services Division
Phone: 0419 122 553    |   Catering Services Division