Backend customisation and be->price_lookup

Neil Williams linux at
Thu Sep 22 16:05:32 EDT 2005

On Thursday 22 September 2005 8:29 pm, Derek Atkins wrote:
> You do a stack trace?  Or are you expecting some calling convention where
> you have to do something like:

I've already decided to change that after your first email - you're right it 
was a bad idea to do it so loosely - it needs the backend context.

> > Once the backend is loaded as a GModule, the only way to cast from
> > QofBackend to FileBackend (or whatever) is by including the header
> > file from the backend itself that declares the FileBackend struct,
> > which means that the module must always be loaded.
> That cast to a FileBackend shouldn't ever happen in QOF; 

It wasn't going to - it was going to happen in gnc-pricedb.c if 
be->price_lookup got simply moved to fbe->price_lookup. Don't worry about it, 
I'd never have done that. I was just illustrating why I started thinking 
about the extension.

> So you're tying the QOF Backend to the Application, and providing a
> way for QOF to translate across.


> Mkay, that makes sense to me. 
> You're putting a generic layer in between the frontend and backend,
> and the two ends are necessarily tied together.

Yes. A supplementary layer that allows specific backends to do more than what 
is currently supportable in QofBackend itself - especially tasks that are too 
application-specific for QOF itself. The application, as you say, therefore 
has to be tied closely to the backend for the task to become available.

I agree - I'd missed the need for the backend context.

I'll see about that QofQuery and put the whole thing on the back burner if 
that works.


Neil Williams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the gnucash-devel mailing list