Dmitry Yemanov wrote:

> Roman,
>> I was thinking rather in the direction of statically linking
>> Firebird database engine (not server) in something bigger,
>> [...]

> I had this kind of thinking as well, separately from the
> whole encryption thing though. Personally, I see it as a
> future Firebird architecture targeted to even tighter
> integration. The engine exposes the hooks that the host
> process (Firebird server or user application) implements for
> the core operation set (mostly access to different resources).
> [...]

These are some quite exciting ideas guys.

For the line protocol you would effectively side-step some of
the issues that Jim spoke of.
. Key/session negotiation and all the pieces that go with
it can become externals
. Licensing issues (as per Jim's concern with OpenSSL etc)
are no longer Firebird's concern

I was thinking that it would be a pain not being able to make
use of the database file for carrying things like the salt
required (and perhaps certificates etc for line encryption).
But if all the storage requests go through my outer app then
I can just move the offsets and create my own database header
(in front of the usual one) and do with it as I want.


And ignoring the encryption aspects, I agree Dmitry, the
ability to isolate configuration and logging from the engine
could be very useful.

You can even envisage odd things like special servers that
don't (necessarily) apply writes to the database file but to
some separate "snapshot" files - ie. Think virtual machines.
That sort of ability may enhance testing over huge databases
(rather than having multiple copies of 400Gb db files you
just work on snapshots over top of them) and so on.

Okay, when can we have it? ;-)

--
Geoff Worboys
Telesis Computing