Backend customisation and be->price_lookup

Derek Atkins warlord at MIT.EDU
Thu Sep 22 15:29:25 EDT 2005

Neil Williams <linux at> writes:

>> This API is not per-backend.  When I call qof_backend_extension_add()
>> with this API, for which backend am I registering this function?  What's
>> the difference between:
>>   qof_backend_extension_add("GNCPriceLookupID", pgendPriceFind);
>> and
>>   qof_backend_extension_add("GNCPriceLookupID", fooendPriceFind);
> It was to be from where it was called. I can change that. That would then 
> create the check on if it is supported.

Eh?  I dont understand.  What do you mean by "from where it was called"?
You do a stack trace?  Or are you expecting some calling convention where
you have to do something like:


This kind of calling convention is bad design, because it fails on a
multi-threaded environment.  It could also fail in a single-threaded
envionment, too, based on the implementation.  You should always pass
the context, or a context name, in the API.

>> >> I don't know.  The current Query mechanism might not provide the full
>> >> requirements for the pricedb searches..  I particular the "closest in
>> >> time" type searches don't quite work right.
>> Frankly, this is probably the _best_ approach, IMHO..  The problem
>> with extensions is that the main code needs to either expect them (in
>> which case they might as well just be in the Backend structure)
> Except they can't because you cannot access the specific backend and the 
> QofBackend cannot contain application-specific handlers.

"cannot"?  It does now -- there's just the one..  ;) QOF hasn't been
failing at all so far.

> 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 should
happen in the FileBackend!  If QOF is assuming that it can cast,
that's BAD.

> This isn't like the configuration options that need to be generic - these 
> extensions will be supported by specific backends to support specific 
> functions in certain applications. As now, the application handles what 
> happens if the backend does not support 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.


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list