Backend customisation and be->price_lookup

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> 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:

  qof_set_current_initializing_module()
  qof_backend_extension_add()
  ...

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

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