Re: JDBC split and move ...

On Sun, 10 Feb 2002, Barry Lind wrote:

> Mark,
>
> OK, now that you have my attention :-)
>
> The first thing I would like to understand here is what is the overall
> plan? You mention things like 'there are serveral pieces...', and
> 'bloated distribution...'. Before agreeing to make jdbc the guinea pig
> of some planned reorginization project, I really want to understand the
> whole plan. What parts of the current source tree go where and what is
> left? (are we talking about all the pl languages being moved as well?)

Over time, anything that is not tied directly into the backend code ...
eventually, I'm even looking at some way of splitting off
interfaces/libpq, since I'm itred of having to download and install an
8Meg distrubtion ust to getl ibpq to compile PHP4 with :(

> How is this going to impact documentation? I strongly feel that things
> like jdbc need to be in the core documentation. Users are going to
> want/expect IMHO a consolidated set of docs for all of postgreSQL. I
> don't think we are doing anyone a service if we make them go searching
> around the internet for various parts of the documentation that may be
> in different formats, etc.

Actually, we're also discussing moving docs into a 'docs project' ...

> How is this going to impact beta testing? I feel that jdbc gets a lot
> of testing when the community at large goes through the process of beta
> testing a new server release. If the proposed change were to occur I
> would still somehow want the jdbc code bundled as part of the server
> betas. (sure people can still get it separately, but fewere will).

The point is to *reduce* the size of the bundles, not increase them ...
with all the changes that went into JDBC, especially since you took it
over, you could have done at least two full releases before v7.2 was
released, for bug fixes and new features that didn't rely on v7.2 itslf
...

> How is this going to impact those who produce binary distributions of
> Postgres? One thing I see as a result of the proposed change is that
> jdbc will not get bundled in many of the binary distributions. It is an
> extra hurdle to have to go pull source from somewhere else and build it
> and it will no longer appear that jdbc is 'part of' postgres, thus why
> should it be bundled in a binary distribution any longer? This will be
> a disservice to end users who will now need to track it down separately.

but, it shouldn't be 'bundled in' ... take a look at the RPMs:

postgresql# ls

postgresql-7.2-1PGDG.i386.rpm postgresql-jdbc-7.2-1PGDG.i386.rpm
postgresql-python-7.2-1PGDG.i386.rpm postgresql-tk-7.2-1PGDG.i386.rpm
postgresql-contrib-7.2-1PGDG.i386.rpm postgresql-libs-7.2-1PGDG.i386.rpm
postgresql-server-7.2-1PGDG.i386.rpm postgresql-devel-7.2-1PGDG.i386.rpm
postgresql-odbc-7.2-1PGDG.i386.rpm postgresql-tcl-7.2-1PGDG.i386.rpm
postgresql-docs-7.2-1PGDG.i386.rpm postgresql-perl-7.2-1PGDG.i386.rpm
postgresql-test-7.2-1PGDG.i386.rpm

its its own distribution ... right now, under FreeBSD ports, you want
*anything*, you hvae to install *everything* ... I so want to be able to
go to /usr/ports/database/pgsql-client and install libpq.a so tht I ca
build PHP4, instead of having to install >5Meg of binares just go get
~150k of libraries .. or be able to go to /usr/ports/java/pgsql-jdbc ...

The point is that if the backend source code isn't a requiremetn for
building jdbc, then I should be able to download it and compile it without
the source code for the backend ...

> All in all, I am seeing a change being proposed here that doesn't
> explain what the whole plan is, what the expected benefits are, and what
> the expected costs are.
>
> With what I know (which isn't much at this point) this doesn't seem like
> it is in the best interest of jdbc or postgres.

Which is why we haven't just gone and done it :)

The whole plan:

remove as much from the 'backend source distributions' as is
possible in order to a) reduce overall packaging size and b) make it
easier for someone wanting JDBC drivers (or ODBC drivers, or python
interface, or etc etc) to be able to build those without having to
download and install everything they do not require ...

Expected benefits:

let's just use an example here that is very "real world" ... I
have a machine that contains 200+ virtual machines ... each of those
'machines' has a requirement for libpq.* to be installed, for PHP4, but
none of them need *anything* else from the distribution ... so that is the
default configuration. Out of those 200+ machines, I've had several
clients start using Java+Tomcat+JDBC for various projects, so to add that
functionality on for them, in order to 'stick with ports' for stuff like
this, I have to re-download (if it isn't already cached) the latest full
distribution (~9Meg) *and* compile the *whole* backend *and* install all
the binaries just to get the jdbc.jar file ... as opposed to just going
into /usr/ports/java/pgsql-jdbc and downloading the jdbc source
distribution, and compiling it against my already existing libpq file ...

Plus, on top of that, didn't just jsut announce new jar files for v7.1 and
v7.2 ... or, rather, they will work under both? So, right now, if I
wanted to compile from source, I have to download the whole v7.2, build
that and hte jdbc drivers, and then manually copy out jdbc.jar ...

Expected Costs:

From my perspective, where I maintain a slew of client machines
with a centralized database server ... reduced time spent downloading and
compiling to get the piece (or pieces) I require on the client machine

As for the 'fewer ppl testing' argument ... how do you figure?
Right now, the only ppl that are testing are those that use/need jdbc ...
if you were to actually *release* 3x for every release of PostgreSQL, and
based on ppl being more apt to *use* a released product vs one just in
beta, the JDBC driver would most likely get *more* use and *better*
testing outside of the PgSQL main stream distribution then in it ...

and this is one of the key reasons why -core started to go down
this route ... there are several *good* projects that are independent of
the backend whose release cycles are tied inot the backends release cycle,
but that *aren't* keyed to it ...