On 08/11/2010 16:35, Dmitry Yemanov wrote:

>
> 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). My first thoughts were about configuration (the engine
> should never read the .conf files, it should be provided with the
> ready-to-use configuration instead) and logging (the engine should not
> write anything into firebird.log itself).

This is very related to what Alex and me talked about the engine plugins
load another plugins (services).

I agree, log and config services should be provided to providers via the
plugin manager. In the end, the y-valve (or in another words, the client
or embedded library) will be the component that will have default
implementation (statically linked) of these plugins.


Adriano