Jim,

> That's the case I'm worrying about -- Firebird 2.0 releases with
> capabilities not available in first Vulcan release, Jaybird releases
> with optional support for those features, then Vulcan releases a
> point release to catch up to Firebird. The problem, then, is that
> Jaybird can't know that Vulcan now has those capabilities without a
> re-release of Jaybird. The capabilities mechanism would let Jaybird
> determine whether a feature was present without having to understand
> the version number.

JayBird 2.0 allows now plugins that are responsible for a particular
GDS API implementation and there is already a plugin for Vulcan that
is also able to customize the JDBC classes.

It seems to be wise to add also a possibility to support plugins
responsible for particular server version. This would solve the issue
without touching the server.

> >However this assumes that the set of the features is finite and all
> >versions implement that API call. Neither is true. I would still
> >have to check the Firebird version for FB 1.0 and FB 1.5 and return
> >correct values there even the call does not exist. Also, if we add
> >some new feature to FB 3.0 or later, JayBird should be updated with
> >a workaround for all pre-FB 3.0 versions to return correct value or
> >throw an error.
> >
> Ask for the capability vector. If you get "item not understood",
> the feature isn't there.

There is nobody to ask - the operation is not defined for the old
servers. I can start asking only from FB 2.0 and Vulcan. For all FB
1.x I have to do it the old way "if (serverVersionMajor == 1) return
...; else return myGDSWrapper.checkFeature(...);".

It solves the problem of re-releasing JayBird with each new server
release, a really small task - takes max. 2-3 hours and filling the
release notes i SF.net release area is the most complex task.

But it does not solve the issue of re-releasing Firebird with each new
JayBird/JDBC specification release if new capability items are added.
For some capability items introduced with new JayBird/JDBC version
"no" would be correct answer, but for others it won't when the feature
corresponding to that item already is present and working. For JayBird
that would mean to check the server version string.

So for now, plugins that can be loaded depending on the server version
seems to be the best solution for this issue. Exactly the same way you
do this with providers in Vulcan.

Roman