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

[Derek Atkins]

linas@linas.org (Linas Vepstas) writes:

> Hmm, these look like 'engine' things.  What's the story on storage?
> i.e. file backend? sql backend?  Or will these magically end up using 
> kvp for everything?

They are "engine" things, but I wanted it separate from the existing
engine.  The business-core is really a "business engine" module, and
business-gnome is the UI.

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.

> I'm slightly concerned about over-specialization: the files
> gncCustomer.h gncEmployee.h gncVendor.h look superficially similar.
> Wouldn't it be better to abstract these into a more generic whole,
> and make the differences between them be a dynamic, runtime flag?
> (i.e. as KVP data?)

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.

I tried to abstract them as best I could, but quite honestly the only
thing I could figure out how to abstract was an Address (contact)
address.  Everything else is pretty much individualized for each type
of entity.

> I am concerned that hardcoding too much in C makes things inflexible:
> for example:  I looked at struct gncEmployee  I saw 'workday' and
> 'rate'.  But real employees may be salaried, or hourly. Salaried
> employees don't have workdays.  Hourly employees have workdays, but 

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

> 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.

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

Good to know.

> Similar remarks for addresses. the evolution contact manager is not bad,
> they hae a nice gui with good flexibility for different address/phone
> numbers, but its still not enough.  I still have to add some address
> info as free-form notes.  

I think that down the road I'd like to integrate into Evolution.
Unfortunately I don't see that as a reasonable option for another
year, once Evolution is actually released.  I.e., I have ZERO plans to
even _look_ at Evolution until it is released, let alone try to
integrate it.  Once it is released, THEN I'll consider integrating
with it's address manager.

> Also, some non-address info: e.g. the last time I talked to them, and
> what was said.  Imagine e.g. a biling dispute .... who said what to whom
> about what bill ....

This is partly what the 'notes' is all about.  I suspect that I'll
also put 'notes' into Invoices and Orders as well.

> I don't want to overload you with work; rather, adding a general kvp
> mechanism should allow handling a lot of this ad-hoc stuff later,
> with less of a dent on the C programming interfaces. 

Point well taken... Now that it's in cvs, feel free to add a kvp
interface.  At this point I plan to move beyond what's been checked in
and onto bigger and better things.

> p.p.s. Derek, Job well done! One has to start somewhere, I shouldn't be
> critical.  Take my comments as constructive.

Thanks.. And definitely.  Even with my sleepiness and multi-beer buzz
as I write this, I accept your compliments and criticism.  Granted, I
don't plan to _act_ on it in the immediate future, but I certainly
agree with you that what I've got is very inflexible, and should be
changed.  But as you said, you've got to start somewhere ;)

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

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available