Subject Re[2]: [ib-support] Why fbembed.dll ?
Author Nando Dessena
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.

PS> I would rather have two .exe files, then adding a lot of extra
PS> baggage to the fbembedded.dll file.

I guess it's a matter of taste. Your solution precludes linking to
both an embedded and a remote server from the same application, just
to save a few hundreds KBs at best. I don't think it's worth it.

PS> After all, embedded is likely to run
PS> on lower end machines, so adding an extra couple of MB to the foot-print
PS> may not be a good idea.

couple of what? :-)
I think only the remote interface would be needed. I'm not able to
quantify, but as I said I'd guess tens or hundreds of KBs at most.

Ciao
--
Nando mailto:nandod@...