GncBusiness v. GNCSession

[Derek Atkins]

linas@linas.org (Linas Vepstas) writes:

> On Wed, Nov 21, 2001 at 08:17:18PM -0500, Derek Atkins was heard to remark:
> > linas@linas.org (Linas Vepstas) writes:
> > 
> > An order entry is a line-item on an Order (either a purchase order
> > or sales order).  For example, a customer orders:
> > 	Object	Qty	Price
> > 	Widget1 1	1.00
> > 	Widget2 1	2.00
> > 	Widget3	1	1.50
> > 
> > Each of these is an Entry.  Each of these could be invoiced
> > separately.
> 
> Hmm.  It suddenly hits me that maybe we really need to start having 
> the 'workflow' conversation.

Maybe (although I must admit that I don't want to build a complete
workflow system right now).  The conversation never hurts.

> Workflow is the idea that you can represent processes in a configurable
> amnner (for example, with XML-based config files).  With workflow,
> you describe a set of objects: e.g. Object A consists of a date, a
> description, a few other fields.  You also describe a set of states, a
> set of state transition rules, and a set of permissions, so that you can
> control who has what permission to move what object from one state to
> another.

Well sure, configurable data is a good thing, to a point.  You still
need to have some core representation of data.  Perhaps the
information beyond that, or the actual labels, can be changed.  But
the data store is still relatively fixed.

For example, the PalmPilot Addressbook provides user-configurable data
fields, to an extent.  The user can, for each record, change the names
of various fields.  There are also four "custom" fields that allows
the user to add additional information.  However, the user cannot add,
say, a fifth custom field.  Nor can they separate the phone number
into separate country-code, city/area-code, exchange, and number
fields.

Similarly in Gnucash, there is a core data representation that needs
to be quazi-static.  Sure, the field names can be changed.  Isn't that
the point of using libglade, to allow customizable dialogs?  Just
change the name of the label in the xml and viola, you have changed
the name of the field.

> For example, a 'bug tracking tool' is a particularly easy thing to 
> to represent as workflow.  A bug has several states: "Open", "Being
> Fixed", "Being Tested", "Closed".  Anyone has the permission to 
> create a new bug report.  Only programmers are allowed to change the
> state from "Open" to "Being Fixed".  Only testers are allowed to 
> move it to "Being Tested".  etc. Everyone has permission to add a note
> (i.e. has permission to modify the "notes" field of the object).

I hope you don't intend to extend Gnucash into a bug-tracking tool?

> Te beauty of workflow is that if you don't like this bug-tracking
> process, you can easily modify it to suit your needs.  You can add 
> more states.  You can alter the permissions graph.  You can add new
> fields (e.g. to track a prt number, if this is a hardware design bug 
> tracking system).

We're talking about two things here..  There is workflow, the way to
define the process of getting from on state to another, and there are
data objects, the data that is moving from state to state.

Having a completely dynamic state machine is relatively easy.  I mean,
shouldn't most of the state machine be coded in scheme, anyways?

Having completely dynamic data objects, on the other hand, is MUCH
more challenging.  The problem is that the storage database is
relatively fixed.  I mean, we can't store EVERYTHING in kvp frames.  I
can't imagine that that would scale very well, and can only imagine
that SQL searches on pure-kvp data, assuming millions of objects (each
with dozens of kvp entries) would really be poor.

Perhaps I'm wrong.  But if that were the case then databases wouldn't
have fixed tables and everything would be dynamic references.  The
fact that tables have rigid structures would seem to imply that there
is a good reason behind the rigidity.

Note that data structure rigidity does not imply UI rigidity.  The
fact that field #5 is labeled 'address2' doesn't mean the user must
see the field as 'address2'.  Indeed, the user could configure their
UI to see field #5 as "customer hair color".

I think that KVP is useful for extending data types, but core data
should still remain just that, core data.

> The other beauty of workflow is that it is powerful enough to describe 
> very broad systems.  Corporate purchase orders, when done by computer,
> are always workflow:  anyone can requisition a chair, but only the boss
> can approve, and then it moves on to the accountant's to-do list for
> final approval, and then it is routed to purchasing.  Its a lot like 
> opening a bug report, and assigning the bug to someone, except that
> the fields are different. 

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.  It should definitely be
flexible.

> You are now moving to an area that is uncomfortably close to workflow.
> 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.

> And the purchase order: I am quite certain that I could poke holes in 
> it, that I could find something to complan about ... Now if I could 
> easily, flexibly, trivially change it, without having to recompile, 
> to re-work giant chunks of the app, without (gosh) having to be a 
> programmer?

As what cost, flexibility?  I certainly have no plans to write the
application that writes the code that writes the XML that changes the
data structures...  Too many levels of indirection for my taste (at
least at this time).  I don't object to the concept, I just don't want
to do that work ;)

> Think about it ..... like really, really, seriously think about it ...

Well, I plan to put all of the "logic" into scheme.  That should make
it relatively easy to change.  As for dialog labels, those are in
glade, again easy to change.  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....  Perhaps guile-gnome or
whatever, maybe.

> > > There are days when I feel I'm reinventing SQL, badly ...
> > 
> > It would be nice if we could have just used SQL directly ;)
>
> There's a reason for that. Many, actually.
> 1) modularity.  If I modified an sql table, I'd have to change gui code
>    all over the planet.
> 2) optimization.  To get good performance, fancy features, the 
>    actual SQL may not be the textbook-intro-101-sql that you'd 
>    write.  For example, to get the account balance in gnucash
>    is a majorly complicated thing. Huge. Thousands of lines of 
>    code.  I want to hid this behind a simpel query "get me bank
>    balance".
> 3) portability.  This follows from 2).  Soon as you start doing 
>    complex things, they are not portable.  And if you are not 1)
>    modular, you are not portable.
> 4) network.  blah blah, client server. blah..
> 5) non-sql backends.  we'd need to find a some sql parser, and tailor it
>    to work for the file backend.  And or the rpc backend, etc.
>
> Although, it may be soon be time to explore 5).

Actually, what I meant was "it would be nice if we only used SQL
backends", or at least backends that ultimately led to SQL.  For
example, one could easily pass a GNCQuery object over the net via RPC,
SOAP, HTTP, whatever and then convert to SQL on the server side.

This whole XML/File thing is just a PitA ;)

As for the GNCQuery... I think that needs an extensibility method,
too.  In particular, it would be nice if a gnucash module could extend
the types of queries, perhaps by adding a typed structure to the
Query.  Basically a way to add an arbitrary, named gncQueryProc()?

-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