Subject | Re[2]: [ib-support] Why fbembed.dll ? |
---|---|
Author | Nando Dessena |
Post date | 2003-05-07T14:37:36Z |
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@...
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@...