Hi Patrick,
I just pushed the files required to build libsynthesis_srv (luz
branch). I also created a simple makefile (src/server_engine_linux.mk)
from the existing, but mostly abandoned client_engine_linux.mk.
I just verifed I can
cd src
make -f server_engine_linux.mk
to make sure all files needed are there and listed in that makefile.
I hope this is enough information to integrate this into the automake
environment as an additional target.
For now, this will create a separate library with the same API
(signature wise, semantics are slightly different, of course) as the
client version of libsynthesis.
To make both server and client libraries linkable into the same app,
libsynthesis_srv defines a different prefix for the entry points:
SySync_srv_xxxxx (defined in serverengine_opensource_linux_prefix.h),
as opposed to SySync_xxxxx for the client variant.
I haven't checked the SDK support code side of things yet, as I'm not
too familar with that (my own use of libsynthesis all uses different
wrappers in ObjC and even Delphi which in turn directly use the C API).
Next I'll work on the code itself to make it actually functional and
push stuff to the luz branch incrementally.
Just a first overview how it will work:
- connecting to libsynthesis_srv and initializing the engine with
config is identical to the client variant. As a starting point for an
XML server config I'd take the syncserv_demo.xml file which is in all
of our free demo server downloads. Of course, I'll push a sample
config for the server libary later into the OS repository.
- all the settings configuration stuff (/profiles/xxx settings keys)
is non-existant in the server. Everything that must be configured is
in the XML config.
- opening a session works the same as in the client, just use
OpenSession(). You can pass the sessionID (the one that will be used
later to identify messages of that session at the transport level,
e.g. using CGI like ?sessionID=xxxxxx) as aSessionName parameter; if
you leave it empty, the engine will create a unique numeric ID of it's
own.
- running the session works similar than in client - but the order of
STEPCMD_xxx is of course a bit different. I'm working on that right
now and will provide more details when it's ready.
- unlike the client library, which can only run one session per
connected library instance, the server engine can run more than one
session in the same instance at a time, and these sessions may also be
run in different threads. It is even possible to switch threads
between processing of each SyncML request in the core engine, but I'll
have to check if this makes sense with the libsynthesis_srv API.
Note however that the engine has a single XML configuration for all
sessions that is parsed in once and then the in-memory tree is
accessed strictly read-only by all sessions.
Best Regards,
Lukas Zeller (l...@synthesis.ch)
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
i...@synthesis.ch, http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
