Backend customisation and be->price_lookup

Derek Atkins warlord at MIT.EDU
Thu Sep 22 14:42:55 EDT 2005

Neil Williams <linux at> writes:

> On Thursday 22 September 2005 6:54 pm, Derek Atkins wrote:
>> Um, don't you want this extension to be per-backend?  E.g. the File
>> Backend and the SQL Backend would want to supply different extensions,
>> no?
> Yes - it is designed that way - sorry if that wasn't clear. It can
> also be shared between backends if that becomes appropriate (can't
> think why it would be used though!)

It's not at all clear because there's nothing in the API that ties the
register or lookup to the specific backend.  There's no backend
context or backend name in the register or lookup APIs.

> Each backend can have as many extensions as it needs, they can be unique to 
> that backend or, theoretically, shared between them.

How would you share an extension?  what would that mean?

>> > qof_backend_extension_add("GNCPriceLookupID", pgendPriceFind);
>> Wouldn't you need this to be per-backend?
> It is - each backend provider initialises their own extension(s) in their 
> QofBackendProvider init function - the one that's called by 
> qof_load_backend_library.

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);
  qof_backend_extension_add("GNCPriceLookupID", fooendPriceFind);

>> > Alternatively, can price_lookup be dropped and a generic (QofQuery)
>> > query used already?
>> 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), or
needs to handle them not being there (in which case it could just have
used the alternate storate/retrival methods in the first place).

So I'm just not seeing what this buys us, necessarily.


       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