On 11/08/10 21: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).

Suppose that this two can be done in FB3. As a side note: this will
solve a problem with providing configuration via API call in much better
way than it was initially supposed.

> The next thought was about the storage (PIO etc), but here I see some
> problems. For example, the engine behavior much depends on various I/O
> options like buffered/unbuffered, persistent/temporary, filesystem/raw,
> etc. Sometimes it's already hard to guess whether some OS supports them
> in the required way and it gets even more complicated in the case of the
> pluggable storage. So it seems we'll need some extra features, i.e.
> request the storage about its supported capabilities and adjust the way
> the engine works based on that. Surely possible, just somewhat beyond
> the current PIO interface.

Sooner of all this means that current PIO interface is too far from
ideal :-)