> PS What happened to that "Firebird Roadmap" to be released "whithin a few
> weeks" (that was several months a go)

It was released and discussed on the Devel List, I guess it should now be
put up on the web site.... For those that missed it:

Future Versions of Firebird....

There has been some discussion re. The future direction of Firebird within the admin group, based on the comments and feedback
there, we believe its now time to throw open the discussion to a wider audience for their feedback and comments.

The proposed development Roadmap is as follows, note this is not cast in stone, and can be modified and amended based on your
opinions.

Currently we have three branches of Firebird code, the current 1.5 code base, Firebird HEAD, the basis for the next major release
and Vulcan.

There is a placeholder to release a V1.5.2 if any regressions are found via the release of V1.5.1.

We would like to freeze new development on HEAD, and use the code to create a Firebird 1.6. Then merge Firebird 1.6 with Vulcan to
create 2.0

For those of you who don't know all the details, HEAD is the current development branch of Firebird within CVS on sourceforge.
Vulcan is an experimental branch that Jim Starkey took from HEAD about 6 months ago to implement fine grained multi-threading (SMP
support) and support for 64bit operating systems based on a development contract that IBPhoenix have with a large software supplier.

Both Firebird 1.6 and Vulcan are likely to be available for “testing” at around the same time, i.e. There are likely to be builds
that users can install, use and play with simultaneously. Essentially during this time i.e. Pre merge users would be choosing
between SMP capability and Firebird 2.0 features.

The rationale for this, is that there is a realisation, that if we tried to do all of the above in one go (2.0 = HEAD+Vulcan), its
going to be a long time before the project can release the next version of Firebird, and this is considered to be not a good thing.

The outline plan is to

HEAD - feature freeze. Should happen as soon as possible. HEAD tagged as 1.6
All incomplete features to be finished. 2.0 Feature must haves to be implemented as soon as possible to include YAFFIL features.
HEAD – Initial alpha release to happen approximately in September. Full Release end of the year?
VULCAN – Initial alpha release to happen in the near future. Futher beta releases as and when available. Final release end of this
year?
FIREBIRD 2.0 – Merge 1.6, with Vulcan, alpha release April/May 2005, with full release towards the end of 2005.

All dates are estimates, there is no guarentee that any date mentioned above is achievable. But we can try.

1.6 will require an upwards compatible ODS version....

So whats in HEAD, YAFFIL and Vulcan?

HEAD

Derived Tables
A derived table is one that is created on-the-fly using the SELECT statement, and referenced just like a regular table or view.
Derived tables exist in memory and can only be referenced by the outer SELECT in which they are created. These are not temporary
tables, an example would be:
e.g. listing managers whose departments have more than 25 employees...
Select e.name, d.department
from employees e
join (select d1.department, d1.mgr_id
from departments d1
join employees e1
on (d1.dept_id = e1.dept_id)
group by d1.department, e1.emp_id
having count (*) > 25) d
on (d.mgr_id = e.emp_id)
Proposed Release: 1.6

New index-structure
Opinion:
The index work declares a new B-tree page layout, this typically would mean a major ODS change. But we consider this work critical
for the next Firebird release. So we will need to find a solution for this.
Proposed Release: 1.6

Auto union-cast
Proposed Release: 1.6

Segment based index selectivity
Arno Brinkman and Dmitry Yemanov have done all the necessary ODS changes. Optimizer to be amended to accommodate the new
statistics. Not complete.
Proposed Release: 1.6

EXECUTE BLOCK syntax
Proposed Release: 1.6

Re-implementation of cursor syntax in PSQL
Proposed Release: 1.6

CANCEL STATEMENT syntax
NOT COMPLETE
Proposed Release: 1.6

Implement physical and multi-level incremental backup
Nbackup needs to be confirmed as complete, documented and tested.
Proposed Release: 1.6

Single-user database maintenance mode and full database shutdown
Two new database shutdown modes:
multi-user maintenance mode – only SYSDBA may access database, GC activities are inhibited (shutdown as it was in Firebird 1.0.x)
single-user maintenance mode – only single SYSDBA connection is allowed to database
complete database shutdown – all connections are denied except to bring database online
Suggested names for switches:
gfix –shut -complete ...
gfix –shut -single ...
-single/-complete may be used in combinations with all currently allowed shutdown flags.
Proposed Release: 1.6

Low disk space conditions
The Temporary File Manager behaves correctly, but the Page Manager is a point of failure. If there is not enough space to store a
new page, then the database may become corrupted. If careful write is working properly – this should not be a problem…
NOT COMPLETE
Proposed Release: 1.6

Windows local connect
IPC to XNET
Proposed Release: 1.6

YAFFIL

Yaffill optimizer improvements
1. Optimized execution of IN (<list>) queries (and multiple ORed equalities,
of course)
2. Allow WHERE A = <value> ORDER BY B to use compound index (A, B)
3. A number of other optimizer bugfixes
Proposed Release: 1.6

Expression Indices
Proposed Release: 1.6

Scale reduction for numerics and decimals
When a result precision is greater than the MAX_PRECISION, the corresponding
scale is reduced to prevent the integral part of a result from being truncated.
Now: D(18, 1) * D(18, 17) = D(18, 17) // Integral part of one digit!?
Should be: D(18, 1) * D(18, 17) = D(18, FIXED_PRECISION) // FIXED_PRECISION
is either hardcoded or configurable. MSSQL and Sybase have it equal to 6
(but their MAX_PRECISION is 38).
Yaffil implements this feature in two ways: DPB flag and non-standard
__MONEY datatype. Our own implementation is still the subject of the separate
discussion.
Proposed Release: 1.6

Incorporate list of 40 internal function implementations
Functions include everything from ib_udf, fbudf, including SQL compliant TRIM/PAD/CHAR_LENGTH etc., other conversion routines and
even regular expression matching.
Opinion:
Will they be available through blr? If so, will they use up 40 more blr values?
Proposed Release: 2.0

Configurable statement timeouts
Proposed Release: 1.6

VULCAN

64-bit Platform Support
64 bit Linux, and other operating system releases.

SMP and Hyper Threading support on Windows
Details:
Make the SS engine fully multi-threaded and SMP-friendly.

Windows local connect
IPC to XNET

Implement full support for concurrently running engines – Win32
Extend Win installer.
Implement an MMC console service to allow the project and third parties to create management tools for Firebird and
have a place to drop them into

Ditto for Linux?
Is it possible to do the equivalent on Linux? Yes

Clean shutdown for Classic servers and processes on Win32
Implement mutexes so that we programmatically and easily close Classic servers. We can then integrate control of the Classic server
into the cpl applet.

Clean shutdown for Classic processes on POSIX
Currently, only kill is available.

Per-database configuration files

Gateways to InterBase and legacy Firebird Servers

Internal SQL

Compiled statement cache (groundwork is in place)

Layerable system tables

Unified engine (superserver/classic/embedded)

Extensible architecture (providers)

OTHER

Simple cross-platform GUI interface tool
Proposed Release: 1.6


Regards
Firebird Project