Although it is quite realistic to release JDBC 1, 2, 3 compatible
drivers one by one, I think the initial architectural decisions
should take into account the move to higher versions. Apart from XA,
support for scrollable and updatable result sets introduced in JDBC 2
is a good example. If this is going to be introduced in a way that
you can move quickly to any row in a 100,000 row result set, surely
it will affect the way result sets are implemented.

I have read Jim's views on the main requirements of web-fronted
databases in another mailing list where he considered latency as the
main issue. I fully agree with that view. For information-based web
sites, how easily and how quickly you can get the data out is the
main criterion in choice of database. More advanced data-processing
and transactional features are seldom needed. Compare the spread of
use of MySql with Postgress and this becomes obvious.

Of course Firebird is in a different league from those databases. The
ability to run with EJB middleware will make it a good match for
jBoss (which has gained a lot of momentum in the past 12 months and
is a good example of a well promoted open-source project).
Realistically though, if a project needs advanced transactional
support now, people would use a database product that has widespread
use among financial institutions. But if XA support is introduced and
enough user interest is generated around Firebird, who knows what the
situation might be in a year or two.

Fred Toussi

> I say if we want to end up with an XA
> capable driver we need to put it in from the start, otherwise it

could be

> just like upgrading interserver to support XA. ( My guess is that
> Interserver was mostly designed to hide 2pc possibilities of

Interbase...

> more top quality engineering).