GncBusiness v. GNCSession

[Derek Atkins]

linas@linas.org (Linas Vepstas) writes:

[lots of good ideas snipped]

> No, at least I wouldn't call it that.  It would be a 'declarative'
> language: something that can declare the field names and types of
> objects, and pretty much nothing more.  
> 
> Think DTD, think XML.  Think of something that mght look like the 
> glade file format, but different.

Ouch, my brain hurts. ;)

> To be practical, it might happen to look like scheme forms and not XML,
> but what I dearly want to prevent is to have the 'declarative' file have 
> arbitrary algorithmic/functional/tail-recursive/lambda-laced scheme
> code.  
> 
> [... snip stuff about billing customer hours ...]
> 
> > > 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.   
> >
> > I'm trying to find it in gtt to see what you did.  As I said earlier,
> 
> if you have the source, look at "design.txt" and  "proj_p.h".
> Otherwise, the strucure is mirrored in the GUI.  Note that different
> billing rates apply to different sub-projects, not different customers.
> Tasks are individually billable at one of several different rates,
> or might not be billable at all.

Of course.  That's why each line-item has a Quantity and a Price.
For non-billable time the Price is zero.  For Billable time the
Price is whatever the rate is for that particular line-item.

Of course this can be changed on a per-line-item basis.  It has
to be.

> > > > 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.  
> 
> OK, Well, its true that one can hard-code stuff fairly quickly, in part
> because there are few conceptual problems.  But I've become
> disenchanted with that approach.  Its boring, its inflexible, its hard
> to maintain, hard to extend, hard to make interoperable with other
> systems (bonobo be damned), etc.  I know that there is a better way.

Sometimes "better" is not necessarily better.  There is really a
trade-off between technological superiority and usable functionality.
If I had to choose between the two, I'd choose the latter (more
functions vs. a highly superior technology).  Sure, this is why
Micro$oft got where they are today (and why some of us hate them --
for selling inferior technology), but there is something to be said
for implementing features.

Moreover, for a Rev 1 of the business applications, having a
relatively inflexible structure is, IMHO, ok.  Even if the Rev 1 work
gets scrapped for a technologically-superior Rev 2, it gets
people to
	a) use the technology,
	b) figute out _HOW_ they use it
	c) figure out what works
	d) figure out what DOESN'T work
	e) Determine how much flexibility you really need.

Do I think I have the end-all, be-all?  Of course not -- I'm
not _THAT_ egotistical ;)

> If the correct tools/infrastructure existed, it could be a *lot* easier 
> to create new, complex apps.  However, creating the right tools & 
> infrastructure is a lot of work...

Yea, yea.. Wishful thinking.  Vaporware.. Stuff like that.  KISS --
hardcoded objects are, IMHO, easier and faster to deal with.

> > >  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.  
> 
> Do you think you have enough info to proceed with this kind of an
> extension to query?  Or do we need to look at it a bit more carefully?

Honestly I think we need to look at it a bit more carefully.  I think
I see where this is heading, but I'm going to have to study the Query
object a bit more before I truly think that I've got it.  Also,
another thing -- currently the Query always returns a GList* of
Splits, no?  How are we going to change that to query other types of
data?

If we could always assume a SQL backend life would be much easier :)

That notwithstanding, what I think we want is the ability to have
nested ANDs and ORs where each QueryTerm has an object-type, and then
an object-specific term and value.

I think I still need to think on this a bit more, in particular how to
extend the Query to return, e.g., a GList* of GncCustomer or a GList*
of GncInvoice, or...

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