> J> Jaybird needs to know about
> J> engine/database capabilities, but can't possibly know about what
> J> future point releases will make those capabilities available.
>
> I assume Jaybird will have to be updated anyway to support future
> capabilities. Or are you implying that there are capabilities about
> which Jaybird knows about already, but it's not known which
> Fb/Vulcan version implements them? If this is the case, then relying
> on the version string won't work, but neither your scheme would.

I was an idea that Firebird/Vulcan returns a value for the set of
already known features. One of the feature JayBird needs is the NULL
sorting order - in Firebird 1.5 they are sorted at the end, in FB 2.0
and Vulcan they are sorted high (end with ASC and start with DESC).
So, if Firebird and its clones return me a sorting order flag, I
should not care about the Firebird version and the problem is solved.
Also there is a call in JDBC to return list of reserved words.

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.

As I wrote before, I think that the best solution is to check the
server and/or ODS version. If JayBird decides it knows what to do with
it, it works, if not - it throws an error. It is even possible to have
JayBird to load different "plugins" for different server/ODS versions
the same way Vulcan works with ODS providers.

> Capabilities are more elegantly extensible, but you can handle the
> future without them pretty well I believe. Plus, the proposal does
> not address the problem of knowing the capabilities for a database
> that doesn't exist yet. Who should I ask whether I can create a
> dialect 3 database or not?

Exactly.

Roman