| Subject | Re: [Firebird-general] Embedded Engine |
|---|---|
| Author | Nando Dessena |
| Post date | 2004-06-22T06:30:43Z |
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.
L> The CURRENT setup should be clear, but even super and classic versions
L> is creating problems, so adding more versions?
Not adding. Absolutely. Rather unifying.
L> The point I am trying to make is probably - Can we simplify things in
L> the short term so we have perhaps ONE setup, which beginners can load
L> and learn, and leave the bells and whistles until FB2/Vulcan allows the
L> difficult stuff to be hidden, and options to be expanded in the config file.
We can. And, we won't get there by crippling the product's
functionality as you implicitly suggest, but by expanding it.
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.
Ciao
--
Nando Dessena
mailto:nandod@...
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.
L> The CURRENT setup should be clear, but even super and classic versions
L> is creating problems, so adding more versions?
Not adding. Absolutely. Rather unifying.
L> The point I am trying to make is probably - Can we simplify things in
L> the short term so we have perhaps ONE setup, which beginners can load
L> and learn, and leave the bells and whistles until FB2/Vulcan allows the
L> difficult stuff to be hidden, and options to be expanded in the config file.
We can. And, we won't get there by crippling the product's
functionality as you implicitly suggest, but by expanding it.
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.
Ciao
--
Nando Dessena
mailto:nandod@...