Questions about the Backend Interface

[Derek Atkins]

linas@linas.org writes:

> Any prefered API? 
> gnc_login(char * username, char * passwd) ?
> This isn't enough for e.g. kerberos authentication, but maybe enough 
> for now?

Good question.  I don't have a good answer.  Assuming this is the
function that the backend calls to ask the user (wouldn't the backend
need some gpointer for window data?), I think a better API might be:

	int gnc_login (char *username, gint32 user_size,
			char *passwd, gint32 pass_size,
			gpointer arg)

This way the backend can tell the UI:
	a) how big the username and password buffers are, and
	b) provide a UI callback arg for windows.

Obviously, this would require the UI to register the CB arg, perhaps
as a part of the 'book_open()' or 'book_load()' backend methods?

> > > 	2) There appears to be no way for the backend to trigger an
> > >            event to the engine/GUI if something happens.  For example,
> > >            I'd like the backend (server) to signal to the engine
> > >            (client) that some information changed, or perhaps even
> > >            pushing the changed information.
> 
> Terminology, as used in gnucash:
> -- backend: the part of the client that knows how to talk to servers.
> -- engine: the part of the client that provides a data cache and a 
>    uniform API to the GUI.
> 
> To answer your question: in practice, the backend can 'push' new data 
> into the engine, because it has access to all the pointers & structures. 

Hrm.  Then perhaps the best way to 'trigger' an event is to have the
server push the new data to the backend, and the backend can then push
it into the engine and notify the engine that the data has changed?

> In principle, there is not yet any set policy: is the engine in charge
> and telling the backend to do its bidding (including optionally handling
> events that the backend generated?)  Or is the backend in charge, 
> mangling engine data as it sees fit?

There are a number of ways of looking at it.  My view is that the
engine (data cache) and backend are all one thing, and the UI is a
second part of the Gnucash client.  Therefore, neither the backend nor
the engine are 'in charge'.  Either can change data, and when it
happens they inform the other half.  Obviously this means that when
the UI changes data, it calls into the backend, and when the backend
changes the cache, it calls into the engine that calls up to the UI.

> Opinions?

Many approaches.  Many choices.  I don't know what's the best way.
I think there are many ways of doing this that are all reasonable.

-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