GncBusiness v. GNCSession

[Linas Vepstas]

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 _-(

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

> Similarly in Gnucash, there is a core data representation that needs
> to be quazi-static.  

Yes. No. Sort-of.  The core data rep would be encoded in a schema/config
file.  It could not be changed once users start using the system.
(some amount of change/upgrade may be possible, maybe, 
but this is a separate important topic).

However, before he system is finally configured, the core data rep 
would be completely and totally configurable in every which way.

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

No. Yes. Sort-of.  If we really build a general workflow system, then
that would be possible.   You could even assign dollar values to each
bug.  But I don't want to get distracted in this pedantic argument.
The point was to illustrate how a workflow system works.

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

Right. But the two are tied together.

> Having completely dynamic data objects, on the other hand, is MUCH
> more challenging.  

No. pseudo-dynamic.  Configurable by sysadmin, but frozen after that
point.

> The problem is that the storage database is relatively fixed.  

I am still thinking about one of several ways to do this in sql.
Each way has different performance characteristics. 

> But if that were the case then databases wouldn't
> have fixed tables 

That would be one way: compile the workflow schema into fixed sql
tables.  But this would make future changes/upgrades/migration
potentially difficult.

> and everything would be dynamic references.  

That would be the other way.  But I am concerned about the performance
of searches/queries in this case.  But I dunno yet.

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

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

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.

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

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

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

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

My apologies to dres, but I can't help but think that there must have
been a far, far easier way.  Frankly, I was expecting that the way 
this would be handled was to write some schemas, and hit a button to
auto-generate all teh xml code.  I did not expect that it would all be
hand-tuned.

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

yes.

> perhaps by adding a typed structure to the Query.  

pehaps.

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

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