Re: [gnome-db] libgda: Public and semi-public API?
- From: Murray Cumming <murrayc murrayc com>
- To: Vivien Malerba <vmalerba gmail com>
- Cc: gnome-db-list <gnome-db-list gnome org>
- Subject: Re: [gnome-db] libgda: Public and semi-public API?
- Date: Tue, 16 Jan 2007 11:02:17 +0100
On Tue, 2007-01-16 at 10:16 +0100, Vivien Malerba wrote:
> On 1/16/07, Murray Cumming <murrayc murrayc com> 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.
Maybe we can use some gtk-doc feature to create groups for these. This
sounds like a good basis for that.
> > 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
--
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]