Hello Jim,

Thanks for the clarification on the subject.

So, basically what you are saying is that it would take a lot of
thinking and conceptual design before implementing the so called
beast, just to make sure that it is well understood.

And, probably because a minority of the programmers using Firebird, it
would be unwise to implement it as an integral part of the database,
but maybe as a plugin for those who want it. This is just to keep the
engine small, unless it would be to compile 2 versions of each
Firebird architecture (SS and CS) for a total of 4, as if 2 wasn't
enough already.

Ah well, maybe in a later version of FB(maybe 3.0 or later). I would
prefer to see SMP support in FB 2.0 SS than cross-database support.

Daniel Rail

Thursday, June 5, 2003, 6:14:14 PM, you wrote:
JS> The short answer is no. The longer answer is that an unimplemented part of
JS> the grand architecture was a beast called the "mega-database manager."

JS> The mega-database manager is a data manager that sat under the Y-valve
JS> parallel to the engine, remote interface, and gateways. The mega-database
JS> manager, in essence, was a virtual database defined in terms or two or
JS> more database, each of which was independently administrated, The
JS> mega-database manager managed virtual database definition, consistent
JS> meta-data presentation, communication, request decomposition, request
JS> execution/synchronization, and two-phase commit.

JS> The original concept was, of course, designed around BLR. Since there is
JS> fairly convincing evidence that BLR is unlikely to kill off SQL in the very
JS> near
JS> future, any serious thinking about the mega-database manager should be
JS> SQL centric, which, unfortunately, precludes any significant reuse of existing
JS> engine code.

JS> All in all, the mega-database manager is probably the same order of magnitude
JS> in size and complexity to the current engine, though the available of large
JS> amounts of memory for meta-data caching would simplify implementation.
JS> The really hard part, however, comes with the realization that 85% of the
JS> mega-database manager is not Interbase/Firebird specific, and with just a
JS> little
JS> bit more work, could work with an arbitrary ODBC/JDBC (pick one) complaint
JS> datamanagers, giving it an independent existence, and changing the economics
JS> drastically. And, unfortunately, probably tripling the size * complexiity *
JS> reliability. Oh well.

JS> da Wolf