sessions, events, queries

[Dave Peticolas]

 writes:
> It's been rumoured that Dave Peticolas said:
> > 
> > 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 ...

Right, I didn't realize we were going to start making the engine
network-aware so soon. Basically, my plan was to extend the engine
event API so that the component manager could tell the engine which
guids it was interested in (the set of all guids for which some
registered component is interested in). This would allow the engine
to negotiate with the 'other side' about which events it needs to
get.

For a demo, I think it would be fine to always send events, since
performance is less of an issue. In the long run, of course, we need
to do something more sophisticated.

I've been thinking about how to handle refreshing when events come
in from the outside. Right now, GnuCash is written with the idea
that reading from the engine is always safe -- the engine isn't
going to change right out from under you and you don't have to do
anything special like read-locking the engine.

Removing that assumption would be quite tricky and I think it would be
easiest and best if we retained the current model. After all, the
engine is supposed to be a local cache for a single front end, so it
should be easy to use.

Given that, I think you need to make changes from the 'outside' appear
as if they could be changes from some other gui component, i.e., they
appear to happen within the confines of the gui event loop.

In gtk, you can have an idle handler that executes when nothing else
is going on in the event loop (which is pretty frequent). I was
envisioning an idle handler along the lines of the following
pseudo-code:

gnc_refresh_idle_handler ()
{
        if (refreshes are suspended)
          return;

        if (engine events are suspended)
          return;

        if (!(engine has stale data))
          return;

        suspend refreshes
        gnc_engine_update_stale_data ()
        resume refreshes
}

dave