On May 7, 2003 10:37 am, Nando Dessena wrote:

> Paul,
>
> PS> The idea is that it should be an either-or ideology either you have
> a PS> full server and client, or you have embedded, rather then some
> mish-mash PS> of both. Having some databases on a central server and
> others local, is PS> asking for trouble.
>
> I respectfully disagree. I don't know how are you going to back up
> your statement, but I can surely envision situations in which a local
> embedded server could be of use *together* with a remote one.
>
> PS> I think what should be the goal though, is that when you install
> FB1.5 or PS> above, that TWO libraries should be accessable,
> fbembedded.lib and PS> fbclient.lib, so that the application developer
> can decide, at the linker PS> stage.
>
> I'd rather link to fbembed only, and let *it* decide, based on the
> connection string. This implies that it should contain the client
> library (being a client to itself). This would be a) simple b) sound
> and c) flexible.

What I would really like is this:

To build you run ./configure which has some options, this could be
replicated with another mechanism under Windows, which builds the
required header file.

./configure wold have three embedded options, --with-no-client
--with-remote-client and --with-separate-client. In the first case it
would be unable to contact a remote server, and would simply return an
error on the connection string, in the second case it would include the
remote client within the fbembedded object, in the third case it would
call that client from an installed fbclient object.

Then the developer/builder can decide what is best for their own
situation, or software.

./configure could become central to the whole build process, in that
other options could be used to build superserver, classic server or
embedded server, client only, developer tools, etc.

Paul S