Re: CLSQL-USQL

On Sun, 4 Apr 2004, Kevin Rosenberg wrote:

> To mimimize download sizes, and perhaps to reinforce the functionality
> of each layer, perhaps 3 different projects should be formed:
>   * clsql-common: the first two layers combined

Most of the database initialisation and connection stuff is common between
CLSQL and CLSQL-USQL. For example:

o support for connection pools is identical.
o support for transactions is more or less identical except the CommonSQL
  spec requires separate functions for committing and rolling back
  transactions.
o connection and disconnection are practically the same.

I think this could usefully all be moved into clsql-base (or clsql-common)
in order to remove code duplication. This package would then provide basic
support for initialising database backends, connecting to and
disconnecting from databases, and returning information about connected
databases (e.g., connected-databases, status etc.).

>   * clsql-classic: the original CLSQL high-leve interface depending on
>     clsql-common
>   * clsql-usql: the original USQL high-level interface dependind on
>     clsql-common
>
> Alternatively, if the clsql-usql interface adds the original CLSQL
> high-level interface, then perhaps that interface could be labeled
> CLSQL and the original high-level interface could be named clsql-lite.

I think the first of these options definitely makes sense and is a safe
bet. I am not sure about the second since I'm not sure quite how cleanly
the CLSQL stuff could be extracted in isolation from CLSQL-USQL and
continue to support the more advanced aspects of the functional interface
to be loaded seperately. I guess it depends on how 'lite' clsql-lite would
want to be.

> I don't feel strongly about the naming and the divisions of
> projects. I'm just like to eliminate code duplication and support both
> users who don't want the overhead of the USQL interface and as well as
> users who want use both the original and USQL interfaces in the same
> application.

Likewise. I think the important think is to separate out according to
functionality so as to accommodate a range of needs (rather than naming).
This database connection/initialisation module with two high-level modules
(e.g., clsql-classic and clsql-usql)  acheives this nicely. Another thing
which could be done quite easily would be to separate the functional and
object-oriented interfaces in CLSQL-USQL. Only the SELECT function which
is common betweent the two would need a bit of work. It seems a lot of
people don't want the OO interface and it is also the least portable part
of the code.

Cheers,
Marcus