Re: JDBC split and move ...

Barry Lind writes:

> Where pgsql, server, jdbc, odbc would each then be a module that could
> be checkedout via cvs.  So if you wanted everything you would just pull
> >from pgsql (cvs checkout pgsql), or you could just pull jdbc (cvs
> checkout jdbc).
>
> I haven't thought about how configure would work in this environment,
> but I would think that there would be a top level configure at the pgsql
> level that would have options like --with-java, --with-server, etc,
> while each individual component would have it's own configure???  not
> sure here.

There are a number of ways to make this work.  The Cygnus (a.k.a. GCC)
tree and the KDE project are examples.  You have a number of related
projects in sibling directories.  Each project uses a GNU-style
configure/make process.  At the top of that tree you have a master
configure script or makefile, either hand-crafted (Cygnus) or
automatically generated (KDE).  The user runs the top configure with the
options he'd like (e.g., --with-pgport=6543 --enable-locale) and the
top-level configure runs each present lower configure in turn with those
options.  There's also a top-level makefile that invokes all the
lower-level ones.

This gives you a certain degree of flexibility and simplification.  Each
configure script only has to deal with a subset of the problem space
(e.g., Java, Perl).  People only have to check out the stuff they want.
You can bundle distributions in different ways.

Note, however, that in spite of this, there's still only one release of
GCC (even though some language front-ends move faster than others at
times) and there's only one release of KDE.

I think the consequences of the perceived faster development in the JDBC
driver should be weighed carefully.  Firstly, the fast development
followed a long period of relative inactivity.  Sooner or later, activity
will level off because all the known and easy problems have been solved.
Secondly, faster development is a matter of perspective.  Consider the
total level of development in the source tree.  When there are enough
changes, why not make a full release that features more JDBC changes than
backend changes?  (Heck, why not make full releases more often period.)

Overall, I'm open to structural improvements, but like Barry I'd like to
see the full plan first, not move JDBC off and see where it goes.

--
Peter Eisentraut   peter_e@gmx.net