Subject Re: [Firebird-general] Embedded Engine
Author Paul Schmidt
On Tue, 2004-06-22 at 02:30, Nando Dessena wrote:
> Lester,
>
> L> The addition of 'Embedded' seems to be confusing people who are just
> L> starting to use Firebird. People who use an 'embedded' engine of some
> L> sort now, and so are asking questions about not wanting network
> L> connections and using mapped drives - because that is what they use now.
>
> In my view Firebird should be made up of a set of components whose
> arrangement is driven by configuration file(s). No question that the
> new superserver is going to rule out classic; this leaves us with SS
> and embedded; I think a single build can support both and also an
> embeddable server, just enable/disable the listener or the embedded
> connection option via conf files. The server and engine should be a
> dynamic library and the server executable (a tiny loader) should use it
> (that's what I proposed in firebird-devel at the end of a long thread
> about embedding the server). You would then be able to distribute 2
> executable files and cover every possible combination. I hope that
> after the Vulcan integration Firebird will support this kind of
> things.

I think to do this properly, you need to keep the SQL interpreter, the
file format, and then build new engine code, you might find it easiest
to build the networking, security and other things needed by a server,
into an embedded application, then use the embedded engine as the core.
If the engine is multi-threaded (no reason why an embedded application,
can't open thousands of connections to the embedded engine), then the
server and utilities like Gbak, become embedded applications.

The key is to provide the most services for the least cost.


> L> MySQL seem to be creating a right mess at the moment with four internal
> L> engines, each with different levels of capability depending on version.
> L> We need to be out there pushing a single Firebird that trumps them :)
>
> We need to concentrate on our market, which is more the enterprise
> segment, and ignore MySQL, which is bound to collapse under its own
> paperload sooner or later.

What MYSql does, doesn't concern me, what does is that so many stupid
programs depend on it......

Paul