CVS update: gnucash/src/business/business-core

[Linas Vepstas]

On Fri, Nov 16, 2001 at 09:30:08PM -0500, Derek Atkins was heard to remark:
> linas@linas.org (Linas Vepstas) writes:
> 
> Right now there is no storage.  You can neither load nor save these
> data structures.  I still have to determine how the business module
> will interface with the backends.  I think part of this is going to
> fall out of the Gnucash engine extensibility work that is going on.

Hmm. Not likely.  There is more-or-less a 1-to-1 correspondence between
the C objects and an SQL table, and an XML node.  Right now, some human 
needs to write the corresponding SQL and/or XML code.  And that is why I
find C structs scary.

I have been vaguely day-dreaming about starting a new project
(or finding & contributing to an existing one) that solves the
'data-driven app' problem the way I want it.    

I want to write an IDL-like thing, and hit a button, and have it
automatically create & read/write the matching SQL tables.  As a bonus, 
the XML code too.  And as a super-bonus, maybe even some of the corba 
or soap code.

Actually, it should be the other way around: the SOAP people should
design something that generates XML suitable for file storage, not 
just network communication.  

I tried to automate some of the low-level SQL code with m4 macros.
Its OK, not great.   I think I know how to go to the next level.   
Hand-generating basic XML code is a total waste of time.  Hand-generating 
SQL code is, well, there are tricky bits, but I don't relish the 
thought of doing it yet again for gtt.  Or for business-core.  Now 
that's code reuse for you.  It should be automated.  Just define 
the structs, and press 'go'.

> Indeed, they are very similar.  Could I use kvp?  Sure.  But does it
> really matter at this point?  Consider the API more than the actual
> implementation.

Well, the API would be quite different.  If I abstracted all three to be
just one thing (address, name, notes), lets call it 'entity'.  Then 
you'd have 

gncEntityGetValue (Entity *, "/employee/workday")

or if you just have the guid, and don't have the pointer to the object:

kvp_frame_get_value ("kvp://0x1234abcd/employee/workday");

So you have a much thinner C api, an API that doesn't change when
you add new features.  From my point of view: SQL tables, or XML,
that doesn't change as you add new features.

> My concept for "workday" and "rate" were for billing customers, not
> for paying employees.

Hmm. A single employee will get billed out at different rates on
different jobs.  A single employee may bill out at different rates
on the same job, depending on both the task, and whether it was performed
at 4 in the morning ...  

I put together what I think is a fairly flexible but still simple 
billing system in gtt.  There are some enumerated billing rate types
associated with each project.   If you are really interested in 
having a gncash module that deals with contractor/conultant billing,
then we should deal with how to merge/interop gtt and gnucash, since I
think I got the conceptual model correct there.

> > may have different overtime and double-overtime rates.  And it gets only
> > more complicated from there (different states, different tax laws in
> > each state, contract relationships, 401K plans, etc.)  So rather than
> > trying to capture all of these in hard-coded C structs, I figure they
> > should be dynamic, semi-user-defined, and go into KVP instead.   
> 
> This is certainly an obvious extension, but quite honestly a "todo
> list" item for me.  I want to get A/R, A/P, Invoicing, etc. done first
> before coming back to this.

Well, right. That was exactly my point.  You're not going to get around
to adding these features anytime soon.  It's not your fault; this stuff
just takes time.  So you need an infrastructure that doesn't set things 
in stone.  I'm scared of the idea of going back some future day and
adding better tax support, and having to modify the C structs, the API,
the SQL tables, the XML file format, the GUI ... ugh.   I would rather
just hack on the GUI, and somehow let the rest of the extension be
handled 'automatically'.

> > e.g. support the following type of KVP URLs:
> > 
> > kvp://0x1234abcd/employee/overtime_rate=10.0
> > kvp://0x1234abcd/employee/401Kplan=yes
> 
> Good to know.

...

> Invoices and Orders as well.

The other thing that I did different in gtt (and this may be
considered heresey by some in the gnucash crowd) is invoicing.

Take a look at the gtt 'primer' (I hope it doesn't crash for you any
more).  I'm not proud of how I handled tables; that might stand some
redesign.  But I really, really, really like the idea that its 
just html code with scheme embedded in it.  I really think it will
be much much easier to customize to match a company's logo/layout.

> If you have any ideas on how to deal with the storage issue, I'd
> really like to hear it :)

See above.  With the current gnucash architecture, storage is a major
sticky-icky point.  Actually, most gnome apps suffer from this.
We need a generic solution.

(The GnuE guys understand this terribly well.  I am sorry to say that
I doubt that the found the right solution.)

--linas


-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933