At 10:09 PM 10/25/02 +0400, Dmitry Yemanov wrote:

>
>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.
>

If you don't need to handle network requests, there's no reason to
run the remote server at all. The system was designed so the
server was properly layered on the callable engine. Reverting to
a single callable engine should be no more than untangling a messy
build system (once simple "make"). If it's going to talking to
a single process, you can probably dummy out the lock manager
as well.

Jim Starkey