On 1/16/07, Murray Cumming <[EMAIL PROTECTED]> wrote: > The new libgda API is very large. I suspect that it's not all useful > from applications. I guess that much of the API is only useful for > implementing providers, and some might even be pure implementation.
The libgda's API could be devided into: 1) the dictionary API 2) the data model and query API 3) the connection 4) the providers API 5) misc other functions The details about the API for each "block" is: 1) for the dictionary API: that API is mainly for internal usage: the end user generally only needs to create a dictionary object, and set its contents (from a file or from a sync. with the DBMS). 2) the data model and query API: it is designed to be used by end users even if there are parts which are more difficult to understand 3) the connection API: it is quite simple and is designed to be used by end users 4) the providers API: end users generally work with a connection and do not access the provider object; this API is largely hidden except for the GdaServerProvider object 5) other functions: a minor part of the total API. > > Are there any plans to make this simpler or more obvious? There is an "easy libgda" API listed at the end of the libgda.h file. > > I don't have a full understanding of how the various objects work > together (documentation?) but I might try using regexxer to figure it > out, and then I might try moving some .h/.c files into a > libgda/providers/ directory. I don't like the idea of making a major sources reorganization at this stage, but I understand the need for a simpler API. What about creating a complete simple API based on the current API, and for example in a simple/ dir (stating for example with the "easy libgda" API)? That simple API can have the minimum to: * open a connection * create and drop a table * run SQL queries and fetch data Vivien _______________________________________________ gnome-db-list mailing list gnome-db-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-db-list
