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/
pgprtDFvQBLiI.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
