Re: [SyncEvolution] libsynthesis_srv

On Thu, 2009-09-24 at 16:21 +0100, Lukas Zeller wrote: I've got it compiled (in fact, already for a while) and working (for not quite that long). I'm not ready to push my changes because I want to test them a bit more. I'm also not entire sure how to solve some of the problems. Previously, clients linked against libsynthesissdk.la, which pulled in libsynthesis.la as a normal library. The SDK's Connect("[]") call would then use the SySync_ConnectEngine and SySync_DisconnectEngine entry exported by libsynthesis.la, without having to open any shared library. This has multiple advantages: 1. everything can be linked into a single executable when compiling the libs as static libraries 2. when linked dynamically, apps run without having to set an LD_LIBRARY_PATH or installing the shared objects (libtool takes care of that) 3. packaging tools automatically determine the right library dependency Now the user of the SDK has to specify in the Connect() call whether he wants "libsynthesis.so.0" (client engine) or "libsynthesisserver.so.0" (server engine). I decided to not remove the undefined references to SySync_ConnectEngine and SySync_DisconnectEngine from libsynthesissdk.la because I wanted to preserve the simple "link everything for client" usage model. This means that apps not wanting that have to provide dummy implementations of these two methods. I'll probably make that available as stub libs inside the Synthesis source code itself, with pkg-config files which match the different configurations: synthesis.pc - link SDK and client engine synthesisserver.pc - link SDK and server engine synthesisboth.pc - link only SDK and all the necessary stubs Better names for the .pc files welcome... synthesisboth.pc only works if --enable-dynamic is used, because the static versions, libsynthesis.a and libsynthesisserver.a, cannot be linked into the same binary. That's because they share classes under the same name and namespace which are compiled differently. Lukas, do you have an estimate for how much work it would be to make these compile-time choices at runtime via if() instead of #ifdef? These two methods are not mutually exclusive, to get more compact libraries the #ifdef could be preserved in addition to the if(). It's probably not nice, but could work like this: if (client) { #ifdef CLIENT #endif } else { #ifdef SERVER #endif } Enabled features would have to be the same in the client and server engine for this to work. Another problem is with the experimental entry points into the engine: * sysync::DataConversion * SySync_DebugPuts The former is only used for testing, which can continue to link against the client engine to get the implementation. The later is now found in SyncEvolution via a dynamic lookup in whatever engine is loaded, so no changes in Synthesis code are needed. Perhaps this would be a good opportunity to make the SySync_DebugPuts available via the normal engine interface and the SDK. This morning I implemented a rudimentary HTTP server in Python which uses the SyncEvolution Connection D-Bus API to pass messages into SyncEvolution. I'm still in the process of figuring out how to interact with the server engine, though. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.