It's been rumoured that Dave Peticolas said:
>
> > > > And now that I'm looking at the event code, there are some truly
> > > > strange things I don't understand ... gnc-event seems to be
> > > > delivering all events to all handlers, since there seems to be only
> > > > one handler list. I was assuming that there would be one list per
> > > > guid, so that only those gui objects interested in that particular
> > > > guid get events pertaining to it.
> > >
> > > For the first pass (without a network interface) I wanted to keep
> > > the engine side of the event api as simple as possible. The other
> > > side (gnc-component-mananger) has an api where components can
> > > specify which guids they are interested in. Right now, the
> > > component mangager does the job of telling the right components
> > > about events. The top-level components (register, reconcile,
> > > etc.) register with the component manager. Only the component
> > > manager registers with the engine.
> >
> > Hmm. Why not move the compnent manager into the engine? I skimmed the
> > code, it looked 99% gui independent ...
>
> It is wholly gui independent, by design, but that doesn't necessarily
> mean it should go into the engine. Maybe it should, but having the
> engine managing gui components seemed wrong. Basically, I think it
> falls into the same class as FileDialog.c or SplitLedger.c.
> Gui-independent, but still not an engine component, because it
> doesn't have anything directly to do with the financial model.
By that argument, I agree. On the other hand, for a network/multiuser
implementation, I've got to send events from server to client, and
the 'engine' is everything that mediates that communication ...
> > > Yes, when we have a network-aware engine, we will need to be more
> > > sophisticated about the engine-side implementation of the event api.
> >
> > Well, I was hoping to create a network aware engine over the weekend,
> > so that I could at least think about some of the harder issues by now.
> > Instead I got hamstrung on this XML thing.
>
> Maybe you should punt and tell Jim to implement Queries<->XML, since
> he's already working on revamping the XML stuff. We're going to need
> it for 2.0 anyway, in order to save reports/graphs. In the meantime
> you could send scheme forms, maybe? You don't really need to send the
> full query api for a demo.
Right. In fact, I've got 10% of the query-xml implemented. You can
take a start-date, end-date query, convert it to xml, and back again.
And that's probably enough to do a demo.
> > ---------
> > BTW, you changed xaccSession to GNCBook. the 'session' was supposed to
> > contain session state (viz, sockets, connection status, etc.). Whereas
> > 'book' is an accounting concept. Its not bad to restrict things so that
> > there can be only one book per session, but it does cloud the picture of
> > 'gee, what structure do I hang the session info off of?'
> >
> > Are you sure you want to continue calling it GNCBook for the long run?
> > Or can we change the name back to 'session'?
>
> There were two thoughts involved there. First, it seems likely that we
> will eventually need to have additional top-level data to store things
> like per-file state (saved reports, etc.) that don't belong to any
> given Account, Split, etc. Thus, GNCBook, though perhaps 'book' is too
> loaded a term. But xaccSession doesn't really convey that meaning.
>
> Second, was the idea that 'session information' should be encapsulated
> by the top-level object, whatever that is, so that the engine knows
> about the 'right thing to do' given the particular backend, but user
> code just deals with 'accounting' objects.
When I wrote this, I forgot about 'Backend', which is another object
that in theory could store session state info. The 'backend' was meant
to define a plugin-api for generic transactional i/o, e.g. sql i/o.
The xml-network demo is using the 'backend' as well, to communicate
to the web server. I haven't thought enough about it to figure out
if an RPC or corba implementation should be 'just another backend'.
In principle, the file-io routines should be changed to be 'just another
backend' as well ... but we'll leave this alone for now.
--linas
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
