> 1) And should have a *_high_* priority.

...

> I believe that if FB is to have any cred
> as a serious contender in middle/heavy-middle
> division of the entreprise db world, then
> good, decent instrumentation *_must_* be
> implemented.

Firebird v2.0 has the beginnings of instrumentation, it's called the
SQLTrace API. The documentation is almost non-existent at the moment,
but that will improve.

> ---------------------
> 2. Also quite important.
>
> Move the code base to 1 (preferably the gcc)
> compiler. Having an Open Source project
> that relies on a Microsoft compiler does little
> for "street cred". It might also help lead to
> 2.5 which is support for the BSD's <insert
> your favourite OS here>. Could also help
> encourage some fresh blood in the programming
> area?

1 - The fact that FB has used the MS compiler for Windows has had
absolutely no impact of getting 'fresh blood'.

2 - Firebird v1.5 had work done to support the MingW (???) Win32
compiler. This has been continued for v2.0.

3 - The codebase has always support gcc for all non-Win32 platforms.

> ---------------------------
> 3. Not sure here. Would a write-ahead log
> give (some) users more confidence? Would it allow
> for PITR?
> ----------------------------

I would argue that write-ahead log would be a determent to Firebird.
The engine is more that able to handle device failures without it.

v2.0 includes a new backup tool, NBackup, which provides for database
image and snapshot backup and recovery functions.

> ----------------------------
> 4. Maybe a system to be able to specify
> different index types for different sorts
> of data - a l'Oracle?

What is the benefit of that?

In v2.0 most of the index handling functions have been rewritten to
address many of the known indexing issues -- and it flies.


Sean