Roman,

> Keyword here is "desktop version for mass market". Installing server
> on each desktop is not the best thing we can do:
>
> a) each desktop that happens to have a copy of that application
> listens on 3050; potential security flaw.
>
> b) there might be a conflicts with network configuration (some other
> application listening on 3050).
>
> c) no administrator rights on WinNT/Win2k machine.
>
> d) ... (I think I can find some other issues, like 'what if they have
> IB there', etc.)
>
> So, in my opinion, embedded database (DLL or built-in) will fit our
> needs better. If that would be a Java application, I would select
> JDataStore (really impressive database)), but that's a native code.

As I've already told you privately, it's not a big deal to build the
embedded server (I have one on my machine and it works via IPC), but it will
definitely conflict with other instances of your app and other programs
listening on 3050. The former will require us to uniquely identify all
synchronization objects within a process. AFAIK, this work is already in
progress. The latter could be eliminated with a proper configuration, but
it's not possible now (it can be done for the standalone server, but we're
talking about another things here), although new config management stuff I'm
currently working on should allow configuration to be available for client
libraries and embedded servers as well. If the embedded server would be
built based on the SS code, then it could handle multiple connections within
the host app. Regardless of the architecture of the embedded version, we
don't have an ability to use 100% in-process transport protocol (at least on
win32), so client-server interaction will be done via shared memory. And we
still don't have a thread-safe client code, so it will be a problem for the
embedded version too.

So I don't think there's any critical limitation to have such an embedded
server, but it requires much additional work. I've already got some amount
of required work done, but that's not enough.


Dmitry