Olivier,

> And there I have to agree it would be good marketing for the project to have some sort of extensibility feature to replace the PIO core, should it be needed (and not only for encryption needs, but for specific storage -- not file based per se for instance). Though if thinking of a loadable PIO replacement scheme, great care should be taken about conditions when the engine accepts to load a replacement IO core module, so that hijacking the whole server does not become kids play.

I was not thinking about loadable thingy. I think that there is more
things to do than just to load the DLL for encrypted storage.

I was thinking rather in the direction of statically linking Firebird
database engine (not server) in something bigger, and that bigger
provides its own means for remote protocol (if any), encrypted storage,
key management, tampering detection, etc.

So, basically, instead of concentrating on a dynamically loadable
encryption provider, we (project) concentrate on making FB embeddable
for those that need it - i.e. clean separation of the remote code
(already done), all PIO stuff (partly done, temp files), gbak and
nbackup, etc.

I see Firebird server as a default implementation of the remote protocol
and PIO code that embeds Firebird engine and is accompanied by all the
drivers, tools, etc. People that need more, should be able to
concentrate on the parts where they are strong and do not dig deep into
FB internals, and vice versa. We might provide something simple to
address the mass market, but that is a side effect.

Roman