[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