Re: [Firebird-devel] Embedded superserver

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

Sean,

S> Ironically, my BroadView application and Nando's are very similar.

unless yours is mainly a legacy C/S application that cannot be
converted to proper 3-tier layered architecture any soon, it is
installed at some 20K sites and has to work on every version of
Windows known to mankind, they are not really that similar. ;-)

S> our application is equally dependant on the FB
S> service/server.

Yes.

S> But the functionality that Nando is suggesting seems to run counter to
S> the appropriate "layering" of the solution.

Yes, it seems so. But I have already stated why I need things this
way. Mine is an *embedded* solution, which means that the logical
layers are all there, but they melt into a single physical executable
program. This is what I call "embedded". I have no control on what
kind of machines it is going to work on. It has to work both as a
service and as an application, it has to be managed by simply starting
an application and stopping the very same application when work is
done, it has to peacefully coexist with whatever version(s) of IB/Fb,
past, present and future the user might decide to install on the
machine, in short: it has to work, always. Due to the costs in terms
of customer support that every little glitch (as little as "I have
seen a process called fbserver.exe on the Task Manager, I thought it
was a virus and I have terminated it") will cause, I need to cut the
possible causes of problems. Having two (more or less) synchronized
processes to do what's essentially an embedded thus by definition
monolithic service is suboptimal in this respect.

I appreciate that there are development and deployment scenarios which
are totally different; as a consultant, I have seen many. I also
understand that it might be difficult to imagine and understand
situations that are so unusual to us.

S> If you want to embed the database into your application than you wrap
S> the application around the engine -- fine.  This means that no outside
S> access is provides to your 'closed' environment or you must expose your
S> own server functions to expose/manage the database access.

FWIW this would be my first choice if I didn't have to a) support a
legacy client application that cannot be easily converted, and b)
provide access to external reporting and datawarehousing tools through
ODBC and the like. So my server has to talk firebird's wire protocol
one way or the other.

S> He wants to completely surround the engine but still provide external
S> 'native' access to the engine.  This appears to be a contradiction.

It might appear so, but I hope I have finally made it clear why it
actually isn't. Bring "embedded" one step further. People is going to
use it. It *does* make sense, and a lot of sense. Firebird is the
*only* enterprise class database that could possibly do it, and we're
still here discussing whether we should allow it or not. Let the
developer decide what's more appropriate in every particular situation
(AFAIK you sponsored the WITH LOCK feature, you should understand what
I mean).

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