GncBusiness v. GNCSession

Derek Atkins warlord@MIT.EDU
23 Nov 2001 20:28:02 -0500


linas@linas.org (Linas Vepstas) writes:

> On Thu, Nov 22, 2001 at 10:05:30PM -0500, Derek Atkins was heard to remark:
> > 
> > Maybe (although I must admit that I don't want to build a complete
> > workflow system right now).  
> 
> Not a complete one, but, given the nature of our conversation, even 
> a primitive sketch of one seems to be taking on a considerable urgency.
> I am concerned that you are planning to hard-code certain structs, and
> that not only will certain users find that the structs are inappropriate
> for the way they want to do business, but that also it would be just as
> easy for you (us?) to code it in a more flexible way.   
> 
> I find the idea just exciting enough that I think I want to carve 
> some time out to work on it.  How far I want to go alone, I don't know:  
> I know that when I go alone, I often find my work undone at a later 
> date _-(

Could you explain to me how you convert from a glade definition
and XML schema to, e.g., gncInvoiceGetValue() or gncCustomerGetName()?

I clearly don't understand data-driven programming well enough.

> > For example, the PalmPilot Addressbook provides user-configurable data
> > fields, to an extent.  
> 
> What I am talking about is a configuration or schema that can only 
> done by the "sysadmin".  Once the configuration has been done, 
> it can be changed only in certain limited ways, and by the admin 
> only: e.g. add/delete users.  I'll need to think about migration
> issues: how much the schema can be changed without breaking
> compatibility.

AHH.. Ok, a quazi-static setup at 'install-time' or 'setup-time' is
certainly reasonable to me.

> Personally I have found that almost every bug tracking system I have
> used was a joke, was poorly defined, and did everything wrong.  
> Except for one ...

Which one? ;)

> Is that a statement that the people who design bug tracking systems are
> idiots?  No.  
> 
> Is that a statement that hard-coding the core structures means that 
> the a weird, foreign way of tracking bugs is imposed on all users, 
> regardless of the problem domain?  Yes.
> 
> The 'enterprise class' folks have figured this out. Oracle and SAP and
> Baan know this.  The GnuE guys know this, although they are pursuing a
> different track, a different way of solving the problem.  Even microsoft
> has been pushing 'data driven development tools' for years.   KDE has
> added data-driven development.
> 
> Personally, I think that 'data-driven' is interesting, but the wrong 
> approach for gnucash.  I think the gnue model is interesting, but too
> general as well.  
> 
> I think that sysadmin-configurable data objects, maybe I should call
> this 'a subset of workflow', to be absolutely the right way to implement
> the business extensions to gnucash.

At some level the logic has to be pre-programmed.  At another level
the logic needs to be flexible.  Similarly, the data structures need
to be pre-programmed and flexible.

I think that we can certainly come up with some hard-coded
requirements for data objects, and some flexibility for extentions.
For example, with a contact-database we can come up with the
required information:
	GUID, Name
Some Optional information (necessary for some instances):
	Terms, Credit
And a lot of variable, flexible information:
	Contact Info

So sure, I can see how you could make the contact database extremely
flexible to suit your needs.  However, , the internal representation
of an invoice (recording a bill and posting it to A/R) has some
required, fixed information:
	GUID, Billed Customer, Accounts and Values (for splits)
Some Optional information:
	Date, Currency

Basically, no matter how flexible you make the system, you absolutely
need this basic information to be present.  I can't see how you could
have it any other way.

Now, flexibility in actually created a PRINTED invoice is certainly a
Good Thing.  When you're going to send out an actual bill, you want
flexibility in how the page is laid out, what is printed, where, and
how.  Sure.  No argument.  But when you post the information to A/R,
you need some basic information to exist and there isn't much
flexibility in that.

> > Again, this is describing the state machine process, not the data
> > structures themselves.  Sure, the process can be scriptable.  As I
> > said, that part should be done in scheme.  
> 
> Scheme is too general.  You don't need scheme to describe a state
> machine.  I don't want to force sysadmins to be coders, much less
> scheme coders.  I want something that a smart accountant could set 
> up.

So you propose creating yet another extension language?  At some level
some programmer needs to code something, even if it's a tool to allow
drag-and-drop of options.

> > > I think that I aleady bitched to you that I didn't like how you 
> > > designed the "employee" object.  Well, wouldn't it be nice if I could 
> > > modify the employee object as I please, only by editing an XML file?  
> > 
> > You can -- run 'glade' and change the labels in employee.glade.
> 
> No. Its not the labels.  It was the fundamental structure.  Like I said,
> I just finished coding the exact same object just a few months ago, and
> I put it in 'gtt'.  I think I got it right there.   But I understand
> that you might not agree.  And I would like to be polite to you.  Which
> is why I want to make this configurable.  So we can each have it our
> way.  Without having to write code.

I'm trying to find it in gtt to see what you did.  As I said earlier,
I agree that with a contact database there is a LOT of flexibility.
However with Orders and Invoices there is much less so.  Are you
specifically talking about the contact database?  Or do you somehow
believe that Orders and Invoices need to be extremely flexible, too?

> > I just don't want
> > to do that work ;)
> 
> It might actually be less work than what you are embarking on.  
> Potentially a *lot* less.  Really.

Considering the contact database is done (except for storage and
complex searches), I don't think so.  Yes, I'm still working on
Order/Invoice entry, but I don't think that a data-driven process can
help me there as much as it would/could for contact information.

> > But show me a tool that will not only
> > generate a dialog but also generate the code that will maintain the
> > data structure for all the information....  
> 
> WISE.  Look at http://www.linas.org/linux/pm.html and search for WISE
> on that page.   I am currently talking to someone who seems like that
> will he taking over maintainership, and possibly/probably re-writing 
> in a major way.  I have a pretty clear idea on how to hook it up to
> glade.  There are some things I don't know yet.
> 
> The gnue guys are working on something similar-but-different.
> See also http://bond.treshna.com/  but I want to take a different
> approach.
> 
> I don't want to force you to do something you don't want to do;
> I do want you to be aware that there is a certain technique that
> I think is not only highly tractable, but is going to result in
> a better system.
> 
> But maybe its up to me to propose something with more specific 
> details.  And for that, I need some time ....

Sure.  I've still got plenty of other things to work on :)

> > Basically a way to add an arbitrary, named gncQueryProc()?
> 
> No. I don't know how to convert arbitrary procs into sql.  Conceptually,
> the query must be representable as a tree, with AND/OR to join the
> branches, and objects (aka tables) & field names & comparison ops 
> appearing in the leafs.   Anything more complex than this is too much.
> 
> All we really need to do is to extend it so that arbitrary objects
> and fields can appear in the query.  This means moving away from
> the enums in sort_type_t, pd_type_t and pr_type_t.  Maybe these 
> should be replaced with strings.  I think if you made them strings,
> then it would be sufficient to get the function that you want.
> I don't think you need anything fancier than this.

Quite honestly yes, this is sufficient.  By arbitrary gncQueryProc()
what I _really_ meant was an arbitrary hook into a module that would
result in a partial SQL query-string.

> --linas

-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