Backend customisation and be->price_lookup

[Neil Williams]

On Thursday 22 September 2005 7:42 pm, Derek Atkins wrote:
> 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.

True. The tie to the backend happens in the backend itself - the extension is 
registered by the QofBackendProvider.

I can look at adding a backend context though. Shouldn't be hard to do.

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

Don't know, it's purely theoretical. It may not become a reality - especially 
if the extension becomes tightly bound to the backend - which, in hindsight, 
it probably should be.

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

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

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.

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.

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

There won't be an alternate method of doing the work within the backend 
because you cannot access the non-QofBackend members of the backend struct.

That's why this would be done via QofBackendProvider.

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

Time to get the libgda backends off the ground?

The current be->price_lookup won't work once QOF is spun out. This provides a 
mechanism to continue support almost as now until such time as a more 
complete solution is available.

-- 

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/4bc0fef9/attachment.bin