Backend customisation and be->price_lookup

[Neil Williams]

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!)

> This way, the *number*, type and IDstring 
> of all backend extensions are entirely determined by the backend in use.

i.e. it is up the backend to decide if it needs 0, 1, 2 or lots of extensions 
- as well as deciding what type of extensions it needs and the IDstrings for 
each one.

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

> > 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.

> > 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.
>
> > Are there any implications for Finance::Quote?
>
> No.

:-) Worth checking.

> -derek

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050922/f82695db/attachment.bin