GObject in GC: A new Library

[Daniel Espinosa]

*A PURE GOBJECT LIBRARY*

*JUSTIFICATION*

GC doesn't use the GObject conventions: the engine re-#define most
functions and data types from QOF and most objects have functions that
may could be better in other object. The problem is evident when I
want to add GObject definitions in each GC's object I can't! I have to
do it in the gnc-engine.h file!; in GObject, a pure GObject
implementation, you define all the API about the object in its files
(.h/.c) and if you want to share functions (use the polymorphic
feature) you define that functions in the base class and the derived
classes doesn't repeat it, just convert this class to the base class
and call the function.

Of course, reach this state in the current GC implementation will take
a lot of time and code. That's way I'm considering to create a pure
GObject library that wraps the actual one.

This 'new' library could help in the following:

* Get reach GObject features from the start, and get an API a la GObject
* Helps other applications to access GC (may be at the same time),
import, export data, using the API (see SHARE DATA WITH EXTERNAL
APPLICATIONS)
* Helps in the separation process of GUI and the app's functionality
* Helps in the creation of a hierarchy were I, or other, could use a
different engine to access the data (see NEW OBJECT HIERARCHY below)


*NEW OBJECT HIERARCHY*

With the following object hierarchy we can add GInterfaces objects to
allow implement the same features in GC/QOF but with different engine
like GDA.

GInterface
 |------>GncBook
 |          This interface will encapsulate all the operations over
collections and backend. The implementers will be unless a QOF based
and a GDA based.
 |
 |------>Gnc's Objects interfaces
            This interface will have the same API as in GC's QOF based objects

GObject
 |------>QofIntance
 |       |---------->QofBook
 |       |              This object will implement GncBook; this
require to add API functions to it. This object will use QOF as data
access framework.
 |       |---------->GC's Objects
 |                      Here are the actual GC's objects.
 |
 |------>GncGdaBook
 |          This object will implement GncBook. This object will use
GDA to access data in database servers.
 |
 |------>GdaObject
         |---------->GncGda's objects
                        This objects will implement the Gnc's
interfaces. This objects will use GDA to access the objects in
database servers.



*WHY USE INTERFACES*

Defining interfaces, we can use diferent engines to access the same
data using the same API with out modifing the interface is posible to
do the same action with diferent implementation: use QOF or GDA with
out notice.

Using interfaces is posible to implement a better solution, using a
diferent engine based different from QOF or GDA, and the parts of the
code that use the GInterface API doesn't need to be modified.


*SHARE DATA WITH EXTERNAL APPLICATIONS*

When a library with this features is shared, external applications
could use it to read, write and update data directly in a real
multiuser/multiaccess environment. This feature could help to develope
diferent ways to allow the user to access its data: an applet on the
panel, a diferent GUI like KDE or HTML, remote access using XML-RPC or
other, this is limited by the developers not by the library it selft,
even that this options are far to be a reality, this library could
help any other to develope its better methods.

*GDA ON GC*

Actually you can access the GC's data using QOF, it has a few backends
(file and PostgreSQL), QOF isn't GObject based and may be never will
completely be.

GDA is pure GObject and allows you to access any data stored in
database servers or systems like SQLite, PostgreSQL, MySQL, MS SQL
Server, MDB and others; it has a lot of functionalities based in
multiuser environments, has objects to get tables as GdaDataModels,
create power full Queries to SELECT, INSERT or UPDATE data directly in
the database server, has objects to manage the database system as
GdaDict for tables, procedures, triggers, etc.

GDA and QOF has almost the same purpose and some similar features, but
GDA is build from the start in GObject and realy easy to expand
creating new backends and new objects based in the power of GObject.

GnomeDB is a set of Widgets based in GTK+, GObject and GDA; its
objects allow to see, add and update data directly in the DataBase.

QOF's queries has just basic features if you compare it with GDA's
queries, because you can select, insert and update data in the
database using the SQL commands, you can JOIN or use other select
command, which allows you to create power full queries. The most
important could be that GdaQuery needs unless a GdaDataModel where to
act, then you need to have mechanisms to get one.

Using GDA in GC will allow to use any database or any backend that can
implement the GdaDataServer interface; even the actual XML based
format used by GC could be implemented as a GdaDataServer. Will help
to introduce GC inside enterprice environments, with few features jet
but with great potencial to grow as an alternative to other accountant
programs, while it could be simple for everyone.

GDA allows to have access to SQLite, a database which could be used by
home user, or PostgreSQL or Oracle database servers for wide use,
multiuser, billion records and so on, for the enterprices.

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
cuates: LIBRE)