GncBusiness v. GNCSession

[Linas Vepstas]

On Wed, Nov 21, 2001 at 02:35:24AM -0800, Dave Peticolas was heard to remark:
> On Wed, 2001-11-21 at 02:08, Linas Vepstas wrote:

> > Ugh.  After a long discussion with dave, he put the guid tables in the
> > session, rather than making them global, 

Ooops, I meant to say 'rather than putting them in the book'.

> you can have more than one session
> open at once, which I believe works right now. 

Excellent.

> It's in a session
> and not a book because it seems to me that metadata belongs in
> sessions, not books. 

I guess I don't understand.  If I have a transaction, and it has 
a guid, and I just read it on one session, and am about to write it
on another session, where does the guid go ???  

I am assuming its possible to have one book associated with 
two sessions, but maybe this assumption is bad ... ?

If I start gnucash for the very first time, and have never saved
to a file before, and just start entering data, is there
a session open?  (I thought there wasn't?)  In that case, if 
there's no session, where is the entity table?

> It could possibly be moved to books, but I
> haven't thought it through. Note you don't need an *open* session
> to create objects, in the sense that it needs to be connected to
> a backend.

Ah ha -- so there must be a session object, it just hasn't been 
'opened' yet.  Sounds like a rump to me.

> I don't quite see the big deal here, though. We need an extra
> argument to all the creation functions in order to avoid a global
> data structure. 

yes, right.

> Whether it's a session, or book, I don't see the
> big deal. 

Well, let me play devils advocate: if its no big deal, then why 
did we separate session from book?  Surely there is a reason.

> To me, sessions are for metadata, like the url where the data
> resides, backend connections and object lookup tables. Books
> are for actual data that gets stored and loaded.

To me, sessions are for managing a persistant data store.  A data
store has to have a URL, a backend, and a mechanism for reporting
network errors.  Mentally, its a glorified socket.

The 'object lookup table' doesn't fit in this paradigm.  Its 
an 'index' for the data, and the index needs to travel with the data, 
it needs to be tied to the data its indexing.  Its not a property 
of the socket or shmat, of the connection to the datastore.

Off-topic: in the future, the session would be a good place to
handle at least some portion of user authentication.  Viz: does this
user have the authority to connect to this data repository?  And if
so, then what are the user's credentials?   This fits the 'connection'
paradigm.

> Now it also has the list of scheduled transactions.
> And eventually the budget data if Joshua's plan
> continues.

I'm sold on the 'core-object' idea, and I think we agree on the overall
picture.  Time to attack the next level of details.

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