Backend customisation and be->price_lookup
linux at codehelp.co.uk
Thu Sep 22 15:01:12 EDT 2005
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);
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050922/4bc0fef9/attachment.bin
More information about the gnucash-devel