9:15 p.m.
Hi,
I have a task to write a "How-to tutorial" for SyncEvolution[1] as part of the
moblin-sdk program[2]. I found the blog article "SyncML Client Do-It-Yourself
Style" [2] written by Patrick fits this quite well. I will probably adapt this a
little to fit into SyncEvolution 0.9 API.
Does anyone has suggestions on this?
[1] 6.2.2 Data sync How to sync data from the mobile device app to the cloud, PC, other
Moblin-based device, or phone*
[2] http://moblin.org/documentation/moblin-sdk/coding-tutorials
[3] http://www.estamos.de/blog/2008/08/04/syncml-client-do-it-yourself-style/
Thanks,
Chen,Congwu
4:59 a.m.
On Mon, 2009-08-24 at 03:15 +0100, Chen, Congwu wrote:
Hi,
I have a task to write a "How-to tutorial" for SyncEvolution[1] as
part of the moblin-sdk program[2].
Excellent! Is this something which can co-publish on syncevolution.org?
I found the blog article "SyncML Client Do-It-Yourself
Style" [2]
written by Patrick fits this quite well. I will probably adapt this a
little to fit into SyncEvolution 0.9 API.
Does anyone has suggestions on this?
I think we should replace the 0.9 backend API as soon as possible. In
other words, review and merge the backend-api into master, then after a
short testing/release cycle release 0.9.1 as replacement for 0.9. This
should include everything that was held back during the feature freeze
for 0.9 (message resend!). A revised GUI D-Bus interface would be nice
too, but is risky.
The "do-it-yourself" guide is indeed a good starting point. There is one
major limitation: the guide and the underlying code + make rules are
designed for people who want to build their own SyncEvolution tailored
for their own backends. Backends are not truly plugable.
The changes necessary to fix this are a bit intrusive, but not
particularly risky:
* install libsyncevolution header files in a standard
path: /usr/include/syncevolution/*.h
* change the #include rules inside these .h files so that they use
"syncevolution/" as prefix for all of them, rename "core"
directory to "syncevolution"
* don't depend on config.h in the header files (apps might not
have the same defines in their own config.h)
* install libsyncevolution.la and add a .pc file for it
* scan a directory for backends to open dynamically in
SyncSource.cpp instead of using a hard-coded list (should also
work when running inside the build directory, with backends in
backends/*/.libs)
Is this something that you could do in combination with updating the
guide?
--
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.
10:08 p.m.
The changes necessary to fix this are a bit intrusive, but not
particularly risky:
* install libsyncevolution header files in a standard
path: /usr/include/syncevolution/*.h
* change the #include rules inside these .h files so that they use
"syncevolution/" as prefix for all of them, rename "core"
directory to "syncevolution"
* don't depend on config.h in the header files (apps might not
have the same defines in their own config.h)
* install libsyncevolution.la and add a .pc file for it
* scan a directory for backends to open dynamically in
SyncSource.cpp instead of using a hard-coded list
(should also work when running inside the build directory, with backends in
backends/*/.libs)
I'm curious how can you implement this? How can we
differentiate the situation whether
it is a production running or a running which is inside the build directory?
2:02 a.m.
On Wed, 2009-09-02 at 04:08 +0100, Chen, Congwu wrote:
>The changes necessary to fix this are a bit intrusive, but not
>particularly risky:
> * install libsyncevolution header files in a standard
> path: /usr/include/syncevolution/*.h
> * change the #include rules inside these .h files so that they use
> "syncevolution/" as prefix for all of them, rename
"core"
> directory to "syncevolution"
> * don't depend on config.h in the header files (apps might not
> have the same defines in their own config.h)
> * install libsyncevolution.la and add a .pc file for it
> * scan a directory for backends to open dynamically in
> SyncSource.cpp instead of using a hard-coded list
>
> (should also work when running inside the build directory, with backends in
> backends/*/.libs)
I'm curious how can you implement this? How can we differentiate the situation
whether
it is a production running or a running which is inside the build directory?
I can't think of any means of making that distinction either. We could
simply scan both the install dir *and* in addition src/backends/*/.libs,
all the time. The latter should take precedence.
--
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.
2:12 a.m.
I can't think of any means of making that distinction either. We
could
simply scan both the install dir *and* in addition src/backends/*/.libs,
all the time. The latter should take precedence.
This has bad limitations: If the
user happened to run syncevolution in a directory with
the same hierarchy, unexpected libraries will be loaded by syncevolution (We will
not have limitation on the name of the backend libraries).
3:25 a.m.
On Wed, 2009-09-02 at 08:12 +0100, Chen, Congwu wrote:
>I can't think of any means of making that distinction either.
We could
>simply scan both the install dir *and* in addition src/backends/*/.libs,
>all the time. The latter should take precedence.
This has bad limitations: If the user happened to run syncevolution in a directory with
the same hierarchy,
We should use the directory where the binary is located (argv[0] works
well enough for that), instead of the current working directory. The
directory of the binary is a bit hard to find, though, and it will be
the .libs directory inside the "src" dir when compiling with
--enable-shared.
--
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.
11:48 p.m.
The changes necessary to fix this are a bit intrusive, but not
particularly risky:
* install libsyncevolution header files in a standard
path: /usr/include/syncevolution/*.h
* change the #include rules inside these .h files so that they use
"syncevolution/" as prefix for all of them, rename "core"
directory to "syncevolution"
* don't depend on config.h in the header files (apps might not
have the same defines in their own config.h)
* install libsyncevolution.la and add a .pc file for it
* scan a directory for backends to open dynamically in
SyncSource.cpp instead of using a hard-coded list (should also
work when running inside the build directory, with backends in
backends/*/.libs)
The change at SyncEvolution side has been pushed to eds
branch, some
points need discussing:
1. To make syncevolution core as a library and remove config.h, I have to add
dependencies for libsyncevolution (eds, glib, etc.); this means a backend developer
who does not touch eds stuff has to install eds library to install libsyncevolution.
2. client-test was always linked to backend libraries even when the backend is
built as dynamic library; I am not sure why it worked like this. I have changed so that
client-test will not link to backend libraries but later dynamically loads the backends
library at runtime if enable-shared is on.
3. We have discussed how to scan possible backend libraries both from a standard path
and the built directory; Patrick pointed out a possible solution to scan the program path
which is passed in as argv[0] in main. This still not worked easily because we are relying
on the static initialization which is before the main routine is called. We may need to
clean up the static initializations if possible.
--
Thanks,
Congwu
3:26 a.m.
On Mon, 2009-09-07 at 05:48 +0100, Chen, Congwu wrote:
The change at SyncEvolution side has been pushed to eds branch,
Can you move it to a separate branch? We might merge it for 0.9.1, as
part of providing a nicer API for external developers, whereas the EDS
enhancements wouldn't bring any benefits for 0.9.1 and thus are material
for 1.0.
some
points need discussing:
1. To make syncevolution core as a library and remove config.h, I have to add
dependencies for libsyncevolution (eds, glib, etc.); this means a backend developer
who does not touch eds stuff has to install eds library to install libsyncevolution.
libsyncevolution.so shouldn't depend on EDS. We should move the
remaining dependencies into a shared library which is used by both the
ecal and ebook backend. Currently, EvolutionSyncSource contains some
code which ends up in both backends, which isn't very clean (lazy
Patrick...).
What exactly are our dependencies? I can think of only one:
* the EDS wrapper layer in eds_abi_wrapper.*, enabled via
--enable-evolution-compatibility
When compiling without that flag and so that only really required shared
objects are linked (CXX="g++ -Wl,--as-needed" CC="gcc
-Wl,--as-needed"),
I end up with a libsynthesis.so which only depends on glib and libsoup,
which I consider good enough for now. If there is a strong need to get
rid of those, we could move the glib/soup (basically introduced by
having the HTTP transport in the lib) into a
"libsyncevolution_gnome.so".
2. client-test was always linked to backend libraries even when the
backend is
built as dynamic library; I am not sure why it worked like this.
You can dlopen() a .so which was already linked.
I have changed so that
client-test will not link to backend libraries but later dynamically loads the backends
library at runtime if enable-shared is on.
Does --enable-unittests still work when doing that?
I'm just wondering, because CPPUnit depends on static registration of
its tests. Loading the backend .so files might happen in time to get
their embedded tests included in the overall CPPUnit suite.
3. We have discussed how to scan possible backend libraries both from
a standard path
and the built directory; Patrick pointed out a possible solution to scan the program
path
which is passed in as argv[0] in main. This still not worked easily because we are
relying
on the static initialization which is before the main routine is called. We may need to
clean up the static initializations if possible.
This may be difficult because the client-test test suites Client::Sync
and Client::Source depend on having a complete list of registered
backends. Creating these tests would have to be moved into main(), after
loading backends. This should be doable and is worthwhile, because right
now the order of global class initialization is somewhat dubious.
--
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.
8:45 a.m.
Can you move it to a separate branch? We might merge it for 0.9.1,
as
part of providing a nicer API for external developers, whereas the EDS
enhancements wouldn't bring any benefits for 0.9.1 and thus are material
for 1.0.
Ah, I will make it.
libsyncevolution.so shouldn't depend on EDS. We should move the
remaining dependencies into a shared library which is used by both the
ecal and ebook backend. Currently, EvolutionSyncSource contains some
code which ends up in both backends, which isn't very clean (lazy
Patrick...).
What exactly are our dependencies? I can think of only one:
* the EDS wrapper layer in eds_abi_wrapper.*, enabled via
--enable-evolution-compatibility
Disable --enable-evolution-compatibility and with --as-needed removed
dependency on eds but after a check there still other dependencies:
libsynthesis, libical, libOrbit, libsqlite3, etc. Looks we better strip such dependencies
to another dynamic library.
> 2. client-test was always linked to backend libraries even when
the backend
is
> built as dynamic library; I am not sure why it worked like this.
You can dlopen() a .so which was already linked.
But in this case, backend developers could not utilize the exiting test framework
out of tree. They still have to link with client-test before runtime (This of course
is a trade off because it will require additional dependency library 'cppunit').
> I have changed so that
> client-test will not link to backend libraries but later dynamically loads the
backends
> library at runtime if enable-shared is on.
Does --enable-unittests still work when doing that?
I'm just wondering, because CPPUnit depends on static registration of
its tests. Loading the backend .so files might happen in time to get
their embedded tests included in the overall CPPUnit suite.
It works, at least 'client-test --help' prints the right information.
However maybe
a cleanup of the global class initiations would be better.
9:03 a.m.
On Tue, 2009-09-08 at 14:45 +0100, Chen, Congwu wrote:
>libsyncevolution.so shouldn't depend on EDS. We should move
the
>remaining dependencies into a shared library which is used by both the
>ecal and ebook backend. Currently, EvolutionSyncSource contains some
>code which ends up in both backends, which isn't very clean (lazy
>Patrick...).
>
>What exactly are our dependencies? I can think of only one:
> * the EDS wrapper layer in eds_abi_wrapper.*, enabled via
> --enable-evolution-compatibility
Disable --enable-evolution-compatibility and with --as-needed removed
dependency on eds but after a check there still other dependencies:
libsynthesis, libical, libOrbit, libsqlite3, etc. Looks we better strip such dependencies
to another dynamic library.
Are you sure these libs are needed by libsyncevolution.so itself
("objdump --all libsyncevolution.so | grep NEED" vs. "ldd
syncevolution.so", which is transitive)?
If SyncEvolution is compiled as shared library *and* the header files
which are included by our header files that are needed by a backend
developer do not include header files of these other libraries, then
their development packages are not needed by a backend developer.
If SyncEvolution is a shared library, then the libraries it needs to not
have to be added to the link line of backends. libtool might not handle
that well, though, which is dealt with by not installing a
libsyncevolution.la and using syncevolution.pc instead (which we don't
have yet).
The second point might be the most problematic one right now, because
there is no strict separation between "external" and "internal"
header
files and thus includes might creep into header files where they don't
belong.
>> 2. client-test was always linked to backend libraries even
when the backend
>is
>> built as dynamic library; I am not sure why it worked like this.
>
>You can dlopen() a .so which was already linked.
But in this case, backend developers could not utilize the exiting test framework
out of tree. They still have to link with client-test before runtime (This of course
is a trade off because it will require additional dependency library 'cppunit').
Yes, out-of-tree extensions to the test system might require more work.
At this point, you probably know better than I what works and what
doesn't ;-)
--
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.
7:52 a.m.
On Tue, 2009-09-08 at 14:45 +0100, Chen, Congwu wrote:
>Can you move it to a separate branch? We might merge it for
0.9.1, as
>part of providing a nicer API for external developers, whereas the EDS
>enhancements wouldn't bring any benefits for 0.9.1 and thus are material
>for 1.0.
Ah, I will make it.
There's the "libsyncevo" branch now. I just had a look at it and have
some comments/questions.
Do we want to install header files in "/usr/include/syncevo" or
"/usr/include/syncevolution"? I suggested the later and still prefer the
full name instead of the shorthand.
If I read the last patch in that branch right, then EDS and glib header
files are now a hard dependency for using libsyncevolution
(syncevolution.pc.in: Requires: libedataserver-1.2 libebook-1.2
libecal-1.2 glib-2.0; #ifdefs removed from several header files). Is
that intentional or is the goal to change that again?
We can keep the config.h usage and the ifdefs in our header files. We
just have to be careful that we include config.h like this
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
and that none of the ifdefs affect structs that are part of the API.
For example, in EvolutionSmartPtr.h, "#ifdef HAVE_GLIB" only adds some
declarations. The header file can be used just fine by a client program
without those if it doesn't provide a config.h or doesn't use GLib
itself.
--
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.
1:10 a.m.
There's the "libsyncevo" branch now. I just had a look
at it and have
some comments/questions.
Do we want to install header files in "/usr/include/syncevo" or
"/usr/include/syncevolution"? I suggested the later and still prefer the
full name instead of the shorthand.
I did not use syncevolution because our binary is already named syncevolution,
which cased two files/directory with the same name under src. Maybe we have to change the
binary name to something like sync-evolution?
If I read the last patch in that branch right, then EDS and glib
header
files are now a hard dependency for using libsyncevolution
(syncevolution.pc.in: Requires: libedataserver-1.2 libebook-1.2
libecal-1.2 glib-2.0; #ifdefs removed from several header files). Is
that intentional or is the goal to change that again?
I am still working on this yet. The goal is to reduce such dependencies by
splitting to another library (With Obex, additional dependencies introduced).
We can keep the config.h usage and the ifdefs in our header files.
We
just have to be careful that we include config.h like this
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
and that none of the ifdefs affect structs that are part of the API.
For example, in EvolutionSmartPtr.h, "#ifdef HAVE_GLIB" only adds some
declarations. The header file can be used just fine by a client program
without those if it doesn't provide a config.h or doesn't use GLib
itself.
Yes, but I will first try to split some non-api stuff to another library
(EvolutionSyncClient, Transport Implemenation)
2:04 a.m.
On Wed, 2009-09-16 at 07:10 +0100, Chen, Congwu wrote:
>There's the "libsyncevo" branch now. I just had a
look at it and have
>some comments/questions.
>
>Do we want to install header files in "/usr/include/syncevo" or
>"/usr/include/syncevolution"? I suggested the later and still prefer the
>full name instead of the shorthand.
I did not use syncevolution because our binary is already named
syncevolution, which cased two files/directory with the same name
under src. Maybe we have to change the binary name to something like
sync-evolution?
Argh, name clash. Hadn't thought of that. No, the command line tool
can't be changed, users probably depend on it in scripts.
Ignoring this particular problem for a second, let's think about whether
"syncevolution" or "syncevo" are more useful in code (include
statements, name space, ...). My only objection against it is that it
still looks unfamiliar to me, but perhaps I should simply get used to
it? One strong point in favor of "syncevo" is that it is shorter and
thus requires less typing.
Thoughts anyone?
>If I read the last patch in that branch right, then EDS and glib
header
>files are now a hard dependency for using libsyncevolution
>(syncevolution.pc.in: Requires: libedataserver-1.2 libebook-1.2
>libecal-1.2 glib-2.0; #ifdefs removed from several header files). Is
>that intentional or is the goal to change that again?
I am still working on this yet. The goal is to reduce such
dependencies by splitting to another library (With Obex, additional
dependencies introduced).
True, but if none of these dependencies' development files are required
when compiling (= we include some of their header files) or linking (=
we provide libsyncevolution as static library or these dependencies
contain static libraries themselves), then it is perfectly possible and
desirable to ignore these additional dependencies.
That libsyncevolution.so is linked against a libfoo.so.1 is transparent,
-lfoo is not needed again when linking against libsyncevolution.so.
>We can keep the config.h usage and the ifdefs in our header
files. We
>just have to be careful that we include config.h like this
> #ifdef HAVE_CONFIG_H
> # include <config.h>
> #endif
>and that none of the ifdefs affect structs that are part of the API.
>
>For example, in EvolutionSmartPtr.h, "#ifdef HAVE_GLIB" only adds some
>declarations. The header file can be used just fine by a client program
>without those if it doesn't provide a config.h or doesn't use GLib
>itself.
Yes, but I will first try to split some non-api stuff to another
library (EvolutionSyncClient, Transport Implemenation)
I'm not entirely convinced that this is necessary. I think a clean API
(self-contained header files which do not expose more than necessary, a
libsyncevolution.so which only exports the public symbols) can also be
achieved without splitting the library.
In fact, if it is only one library, then we can hide the internal
symbols in the libsyncevolution.so, like it is already done in
libsynthesis.so. If we have multiple libraries (libsyncevolution.so with
the API, libsyncevolution_internal.so with the implementation), then all
internal symbols which are needed by libsyncevolution.so must be
exported by libsyncevolution_internal.so and therefore are visible
globally when linking.
--
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.
4152
days inactive
4175
days old
syncevolution@synevolution.org
13 comments
2 participants
participants (2)
-
Chen, Congwu -
Patrick Ohly