GncBusiness v. GNCSession

[Linas Vepstas]

On Mon, Nov 19, 2001 at 08:09:51PM -0500, Derek Atkins was heard to remark:
> linas@linas.org (Linas Vepstas) writes:
> 
> > On Mon, Nov 19, 2001 at 04:42:47PM -0500, Derek Atkins was heard to remark:
> > > Linas, can you look at src/business/business-core/gncBusiness.c?  In
> > > particular, look at the registration process, where the business
> > > objects register themselves with the "business engine".  I think this
> > > registration is better off in the engine as part of the GNCSession.
> > 
> > Actually, probably in GNCBook.  A 'session' is supposed to correspond to 
> > a user sitting in front of a keyboard, connected to some data
> > respository.  A 'book' is supposed represent the collection of data 
> > you are currently working with.  The book can hold on to data even 
> > while disconnected from a backend (e.g. during a copy from one 
> > backend to another).  (Maybe the book is a good place for those poor 
> > orphaned currencies).
> 
> Um, I think you misunderstood what the registration does... It doesn't
> register an instance of a business object -- it registers the business
> object "class".  It's a static global, and is done at program
> initialization time.  

write now, gnucash doesn't have any structure that holds 'static
globals', not unless Dave snuck one in there while I wasn't looking.

> The second step is an Entity Table, and those
> belong in the Session.  

I don't know what an 'entity' is.  The session table is really meant to
hold network connection things.   Note that if there is no open
connection to a file or sql (or rpc) backend, there is no session.
(At least, thats how it used to work...)

You can use gnucash without having a session: you just won't be able to
save your work until you do start a session.  

> I agree that the entities themselves should be
> stored in the book.  Based on that, there seems to be a might tighter
> relationship between the Session and the Book.

Well, they used to be together, but dave recently split them apart. 
I don't think we have a terribly well articulated policy of what each
is really for.  I don't think we've ever talked about (i.e. have in
writing, in the documentation), for what 'should' happen one copies
data from one session to another, or what it really means to run without
having an open session, or whether its possible to have more than one
open session at once.  (right now, its not, but is that a feature, or a
bug?)

For example, there is a bit of ugliness with how the backend is used.
The 'requirement' is to have a pointer to the backend to be easily
and quickly accessible to engine routines.  Currently, the somewhat
ugly solution to this requirement is that many of the structures 
in the engine contain a pointer to the backend.  This is not ideal, 
and is confusing.


> Well, this is in lieu of moving the business objects into the engine.
> I can always do that if you want, but I was hoping to keep it
> separate.  If you want it all integrated, that's fine with me -- it
> would make life much easier.

'integrated' is a word that has shades of grey.  If you just want a few
pointers in some struct to dangle your data from, I have no objections.  
But if you start accessing other engine data members without using the 
formal API, well, that might not be so good.  

> > 2) If you *did* want to write an extension mechanism, it would probably
> >    be for gnc-session and gnc-book, not the backend.  The book is where
> >    you would dangle your data from, the session is where you would
> >    dangle your network connections from, and at that point, you are 
> >    free to invent your own backend; you wouldn't need (and shouldn't
> >    use) the existing backend. 
> 
> I'm not convinced with your final statements..  I agree that the
> session should store entity state and books should store data.
> However, the business data _is_ related to the rest of a book (aka
> Chart of Accounts) and should not be separated.  Separating it would
> make no sense, and might cause problems.  By that argument, Scheduled
> Transactions should be separated out of a book as well.

What you understand is not what I meant.  What I meant to say was that 
you don't have to use the current "struct Backend" to access the data 
store.  All you really need to do is to provide some vector table so 
that other people can write methods to access other storage media. 

I do beleive that a storage backend for business objects will probably
be very tightly integrated with the engine backend.   But that does
not mean that business object calls have to flow through the current
'struct backend' to acheive this.  There's nothing wrong (that I see)
with design a different 'struct busns_back' for use by the business
objects; I also se a few advantages for keeping it separate.  The
actual code underneath 'struct busns_back' might be very tightly
integrate with the the code underneath 'struct backend', but that
is an implementation issue, not an architecture issue.


> >    The hard part, that I haven't thought through, is how to find 
> >    your extension given a single URL.  i.e. when the user does
> >    a gnucash->open from the menus, how do we find your extensions?
> 
> My point is that it _should not_ be a separate URL.  

yes, I agree, from the user perspective, it should be enough to specify
one URL to find the package deal.

> It should be
> stored in one place.  

Sure, whatever, that's an implementation issue.  I don't care.

> MY question is: how do you extend the backend to
> know about new objects?

There are several ways.  The one you seem to want is to add new vectors
to 'struct backend'.  But that is not the only (or best?) option.  

I'm proposing:
Add a pointer in GNCSession to point at your business class.  
Your business class  contain a pointer to a 'struct BusinessBackend'
which you can define as you wish.   

Does that make sense?

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