Vulcan Priorites

Vulcan's highest priority is Firebird 2.0 coexistence. Vulcan and
Firebird 2.0 should be serially shared database files. To this end,
Vulcan needs to bring its ODS up to that of Firebird 2.0. The Vulcan
ODS is based on a bastard snapshot of the Firebird 2.0 development tree
a year ago last December. To the best of my knowledge, and I may well
be wrong, the major difference is index structure. Vulcan desperately
needs Arno's extended indexes. The conversion shouldn't be difficult --
btr.cpp was lightly touched -- and while the page cache manager has been
heavily rebuilt, the macros used for interface has been redefined. The
second part of coexistence is making sure that Vulcan and Firebird 2.0
don't trip over each other. For better or worse, the requirement to
support fine granularity threading dictated a change to the lock manager
format, so actually sharing a database between Vulcan and Firebird 2.0
is out of the question. We should, however, make sure that Vulcan uses
a different lock file with an appropriately different header. I think
we also need to solve, for once and all, a strategy that ensures that
two engines never try to shared a database file using different lock
managers. I'll make this the subject of a different post.

I think the second priority is fixing the Linux/Unix build procedure.
The procedure in place is strictly ad hoc for my personal convenience.
It needs to support building outside of the source directories,
differential build for production releases, and support for hybrid 32/64
releases. The dependency on autoconfig is definitely a problem for
platforms that support both 32 and 64 bit executables. Buildgen is
design to generate "stuff" from component specific Visual Studio 7
project files. Right now it generates complete makefiles. I could also
be used in a more limited way to generate make include files to be used
with component specific, hand maintained makefiles.

The third priority is re-implementing the "execute sql" statement and
building a "services" provider. The Vulcan architecture has full
support for the services API in both user interface and the generic
provider class, but there isn't yet a services provider to field the
calls. The difficult problem is that the individual standalone
utilities that comprise the services module are a profound mess,
containing references to internal engine functions, engine threading,
engine thread data, and engine synchronization primitives, none of which
exist anymore. It's an open question of whether to the "services"
builds of the components or just start over. I don't know. Somebody
needs to do a careful investigation and make a recommendation.

The fourth priority is general improvements. This is include new
features and bug fixes from Firebird 2.0 and general upgrades of the
code, specifically including continuation of the engine mechanism
encapsulation process. The most important of these is the
transformation of the RSB mechanism into a proper C++ hierarchy.