Nando Dessena wrote:

>J> Not true. The problem is real and immediate.
>
>then you should perhaps have started by describing the problem instead
>of throwing in a detailed solution inclusive of the binary layout of
>the required structures. IOW, I think you should have done as you
>frequently preach others to do. :-)
>
>Thanks for fixing this by disclosing this info.
>Anyway, I am not sure I see the problem even now (I might just be
>thick).
>

You are right. The discussion actually started on the admin list with
Roman worrying about how Jaybird was going to cope with overlapping
Firebird 2.0 and Vulcan releases with different capabilities. As you
say, I should have started with a re-cap of the problem rather than a
solution to an unstated problem.

>
>
>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.
>

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.

The idea is to allow a layered product to run intelligently on various
versions without having to release after every Firebird and/or Vulcan
release. If Jaybird is dependent on version strings, it must re-release
after each and every database release.

>
>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?
>
>
>

I've been doing this a long time now. I still get surprised, but the
surprises are now very familiar.

As for your second point, create the database and ask? What else could
you do? Personally, I think the idea of database dialect is remarkably
dumb, but that's a different question.