[Fwd: [Gnucash-changes] r13084 - gnucash/trunk - Fix overall and ".log"-specific file-retention issues: Bug#329670 (++).]

Neil Williams linux at codehelp.co.uk
Fri Feb 3 18:52:56 EST 2006


On Friday 03 February 2006 10:36 pm, Josh Sled wrote:
> On Fri, 2006-02-03 at 22:10 +0000, Neil Williams wrote:
> > The bug is actually in the gnc-backend-file - it should initialise the
> > "be" configuration itself in the call to :
> > session->backend = (*(prov->backend_new))();
> > Repeating the call in the very next line should not be necessary.
>
> Why does the framework want backends to define interface methods that
> the framework doesn't actually use? 

Data-centric design.

Just like many other components of QofBackend, this is supported to provide an 
interface between the backend and the application. QOF mirrors the 
information from the backend (which cannot be linked against the application 
directly) to the application.

It's also how the translated tooltip and description strings for each backend 
are made available to the application (the main reason for using a KvpFrame 
in the first place).

http://www.data-freedom.org/explain.html#example
Therefore any program that can exchange data with QOF can use whichever 
backend is suitable. Any other QOF compatible program can read the data, even 
if it doesn't use that backend normally. This increases platform 
independence, data accessibility and program flexibility.

> What's the point of having a 
> backend declare its options to QOF?

So that any application using QOF can query the configuration options for any 
QOF backend without having to be linked against the backend itself (which it 
can't be in any portable way).

Remember that QOF backends can be installed independently of any application 
and vice-versa. gnucash relies on gnc-backend-file and QSF but future 
backends will not have such strict limits. Applications will need to be able 
to read the configuration of these backend modules at runtime and decide how 
to use the available options.

e.g. I plan to use libgda to provide any QOF process with access to any of the 
databases supported by the gnome-db project. The various configuration 
options of these modules will be passed up to the application via the 
KvpFrame. The application will not be able to determine at compile time which 
precise backend module is to be used (other than sql://) as it will depend on 
which modules the user has installed. All the application will see is a 
standard QofBackend that can run queries in the backend, has a local cache of 
entities etc., and which has N configuration options that the application may 
or may not choose to use.

The KvpFrame is sufficiently flexible for this because although the 
application can set any option, the backend only reads the options which it 
understands. The reverse is also true - the application can choose to present 
the user with only those options it understands, the others are left as 
defaults.

QOF processes can only communicate with the backends via qof_session_* and the 
supported configuration options. Equally, QofBackends can only receive config 
options and a QofSession/QofQuery. QOF must act as the gopher for the config 
options, just as it does for the objects themselves.

The application must declare it's objects to QOF so that the backend can 
operate; the backend must declare it's options, if any, to the application so 
that the application can use the options.

-- 

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/20060203/8d82c87c/attachment.bin


More information about the gnucash-devel mailing list