Re: [Firebird-devel] Embedded superserver

[Nando D. <na...@de...>]

Jim,

J> Let me start with some definition so we have a common vocabulary:

Thanks; I think this could help simplifying a discussion that's going
a bit astray...

I agree with all the definitions, particularly this one:

J>     * Embedded -- an ambiguous reference to an engine

:-(

Perhaps the thread should change subject. I shouldn't have used a word
having such precise connotation in firebird parlance like "embedded".

J> The highest bandwidth path to the database is always a direct call.
J> Applications that require the highest bandwidth access have a number of
J> alternatives

This is not my requirement, although it would be nice not having to go
through TCP/IP to talk to an engine that lives in my own address space.

According to the vocabulary you have so gently set up, my requirement
is having a superserver engine + server loadable as a dynamic library,
with a function to start the server (possibly passing in a command
line or equivalent switches or parameter block) and a function to stop it.

J>    1. Exclusive embedded access with the existing Firebird embedded engine
J>    2. Shared embedded access with classic engine
J>    3. Adding specialized application code to database servers accessed
J>       by IPC or wire protocol
J>    4. Running database server threads in application process
J>    5. (Sharing database in classic mode with Vulcan multi-client server)

I think 4 is closest to my requirement, but I'm not sure whether
"running database server threads" is the same as "running an engine"
or not. If it is, then 4 is what I need. I am aware that 3 is much
more common and I am actually using it right now.
I am also using 1 for some things, BTW.

J> The historical goal of all database architectures is to move semantics
J> closer to the disk platers.  This is the reason for high level language
J> semantics (SQL vs. the earlier navigational interfaces), triggers, 
J> stored procedures, and plugins.  But the closer something gets to the
J> disk, the more difficult it is to write, debug, and support.  For most
J> applications requiring very high bandwidth database connections, outside
J> the engine but inside the server is a very good compromise, and one that
J> we should work to support.  I'm not suggesting (and would oppose) 
J> defining the internal architect of a database server process.  A clean,
J> modular, class design is sufficient.

Outside the engine, inside the server. I guess that sums it up.

Ciao
-- 
Nando Dessena
mailto:na...@de...