opensync-devel — The place to coordinate the development of OpenSync

Re: [Opensync-devel] [PATCH] Small memoryleak fixed in serializer.c

[Chris F. <cd...@fo...>]

On Fri, Jul 15, 2011 at 01:24:31AM -0400, Chris Frey wrote:
> Yeah, I've been breaking open the valgrind as well.  There's quite a
> bit to fix.  Also, my commit 2e54e5125aee9d0a4d8479c1276b7cc49db82677
> doesn't quite fix the issue entirely.  If you find you encounter crashes
> during sync, just revert that commit in your repo until I find the
> official fix.  It is slow going, following the logic through client
> proxy, client, and the message queue. :-)

This bug has been fixed in commit 8027c2774c9ee25797734bd4594a8ec5a54c1217

- Chris

Re: [Opensync-devel] [PATCH] Small memoryleak fixed in serializer.c

[Chris F. <cd...@fo...>]

On Fri, Jul 15, 2011 at 02:15:21AM -0300, Luiz Angelo Daros de Luca wrote:
> Hello,
> 
> While playing with valgrind, I found some small memory leaks.
> I fixed what it found in serializer.c and another one that it did not
> found. My code is in:
> 
> git://github.com/luizluca/opensync-luizluca.git   fix-memoryleak-serializer

Thanks, I've merged that.


> The first do some formatting cleanup (kdeveloper help) and the other
> ones are the real fixes.
> 
> BTW, there is more memory leaks in code. I just didn't stopped to fix them.

Yeah, I've been breaking open the valgrind as well.  There's quite a
bit to fix.  Also, my commit 2e54e5125aee9d0a4d8479c1276b7cc49db82677
doesn't quite fix the issue entirely.  If you find you encounter crashes
during sync, just revert that commit in your repo until I find the
official fix.  It is slow going, following the logic through client
proxy, client, and the message queue. :-)

- Chris

[Opensync-devel] [PATCH] Small memoryleak fixed in serializer.c

[Luiz A. D. de L. <lui...@gm...>]

Hello,

While playing with valgrind, I found some small memory leaks.
I fixed what it found in serializer.c and another one that it did not
found. My code is in:

git://github.com/luizluca/opensync-luizluca.git   fix-memoryleak-serializer

The first do some formatting cleanup (kdeveloper help) and the other
ones are the real fixes.

BTW, there is more memory leaks in code. I just didn't stopped to fix them.

Regards,

---
     Luiz Angelo Daros de Luca, Me.
            lui...@gm...

Re: [Opensync-devel] Problem with conversions that use objtype data (like in file-sync)

[Chris F. <cd...@fo...>]

On Thu, Jul 14, 2011 at 12:32:18AM +0200, Daniel Gollub wrote:
> On Wednesday, July 13, 2011 03:11:26 AM Luiz Angelo Daros de Luca wrote:
> > I'm not sure but I don't see a reason why and objtype need to change
> > and why it relies on the target format objtype instead of the change
> > objtype.
> 
> One common case is:
> 
>  * mobile phones which use a "calendar" object type - which is actually a mix 
>    of "todo" and "event". Some devices store those in different datastores, 
>    some mix those.

Wow, wild! :-)  Does this seem like a good idea?  How does the opensync
engine differentiate these data types?  Do the converters convert one
mixed objtype into, say, 2 or 3 different ones?

- Chris

Re: [Opensync-devel] Problem with conversions that use objtype data (like in file-sync)

[Chris F. <cd...@fo...>]

On Thu, Jul 14, 2011 at 12:39:01AM +0200, Daniel Gollub wrote:
> On Tuesday, July 12, 2011 11:35:37 PM Chris Frey wrote:
> > > Who is wrong? opensync? file-sync? myself :-)?
> > 
> > It took a while, but I finally found the "plain"/"data" objformat
> > in the xmlformat plugin, in xmlformat_note_memo.c.  Ouch. :-)
> 
> Ouch ... it's also in file-sync/plain.c
> 
> Need to check svn history how it made it to xmlformat_note_memo.c ...

Looks like it was just included during development and never used.
It is not referenced by the CMakeLists.txt file either, and neither
are many of the xmlformat-*.h headers used in the .c code.

I've cleaned up the code a bit in my git repos.

Thanks for the file-sync plain pointer... looks like that's where
it officially resides.  Which makes file-sync kind of a required
plugin, right?

- Chris

Re: [Opensync-devel] Problem with conversions that use objtype data (like in file-sync)

[Daniel G. <go...@b1...>]

On Tuesday, July 12, 2011 11:35:37 PM Chris Frey wrote:
> > Who is wrong? opensync? file-sync? myself :-)?
> 
> It took a while, but I finally found the "plain"/"data" objformat
> in the xmlformat plugin, in xmlformat_note_memo.c.  Ouch. :-)

Ouch ... it's also in file-sync/plain.c

Need to check svn history how it made it to xmlformat_note_memo.c ...

Best Regards,
Daniel

-- 
Daniel Gollub
Linux Consultant & Developer
Tel.: +49-160 47 73 970 
Mail: go...@b1...

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Re: [Opensync-devel] Problem with conversions that use objtype data (like in file-sync)

[Daniel G. <go...@b1...>]

On Tuesday, July 12, 2011 11:35:37 PM Chris Frey wrote:
> > According to http://www.opensync.org/wiki/glossary, "Conversion can
> > change the format of an object but never its type."
> > Is this still true?
> 
> I suspect it is not true.

Right, this not true, at least it's not true anymore for trunk.

I corrected the statement in the glossary.

Best Regards,
Daniel

-- 
Daniel Gollub
Linux Consultant & Developer
Tel.: +49-160 47 73 970 
Mail: go...@b1...

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Re: [Opensync-devel] Problem with conversions that use objtype data (like in file-sync)

[Daniel G. <go...@b1...>]

On Wednesday, July 13, 2011 03:11:26 AM Luiz Angelo Daros de Luca wrote:
> I'm not sure but I don't see a reason why and objtype need to change
> and why it relies on the target format objtype instead of the change
> objtype.

One common case is:

 * mobile phones which use a "calendar" object type - which is actually a mix 
   of "todo" and "event". Some devices store those in different datastores, 
   some mix those.

There might be also other formats/data which require this kind of mix-objtype 
handling.


Best Regards,
Daniel


-- 
Daniel Gollub
Linux Consultant & Developer
Tel.: +49-160 47 73 970 
Mail: go...@b1...

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Re: [Opensync-devel] Problem with conversions that use objtype data (like in file-sync)

[Daniel G. <go...@b1...>]

On Tuesday, July 12, 2011 11:44:25 PM Chris Frey wrote:
> Daniel: Is is possible for the user to disable converter detectors?
> Is there any drawback to this that I'm not seeing?

It is possible to disable convertors completely. But not just (converter) 
detectors, at least not yet.

Not quite sure about any drawbacks. You might give it a try by introducing a 
switch enabling/disabling just (converter) detectors.

Maybe it would be also interesting to make the OSyncFormatEnv per group 
configurable. So you can white-/blacklist which convertors/detectors should 
get prefered or shouldn't be used at all.

Do you think this might help? Also in terms of getting things working kind of 
"out-of-the-box"?

Best Regards,
Daniel

-- 
Daniel Gollub
Linux Consultant & Developer
Tel.: +49-160 47 73 970 
Mail: go...@b1...

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Re: [Opensync-devel] Problem with conversions that use objtype data (like in file-sync)

[Luiz A. D. de L. <lui...@gm...>]

Hello Chris,

Thanks for your answer. I forgot to say that this once worked in 0.39.
Maybe this is a regression.
Could you confirm the problem in your build tree? I use two simple
vcard like this (with different names):

BEGIN:VCARD
EMAIL:te...@te...
FN:teste
N:teste;;;;
UID:AQwmWWYIkq
VERSION:2.1
END:VCARD

and

osynctool --addgroup testme2
osynctool --addmember testme2 file-sync file1
osynctool --addmember testme2 file-sync file2
osynctool --configure testme2 1
osynctool --configure testme2 2

The first I use path that contains my vcard and the second one points
to a empty dir.

If I force the objtype to be "contact" in my plain format, it works.

I'm not sure but I don't see a reason why and objtype need to change
and why it relies on the target format objtype instead of the change
objtype. In osync_format_env_convert, it could save the objtype of the
input data and apply to the converted one.

Thanks,

---
     Luiz Angelo Daros de Luca, Me.
            lui...@gm...



2011/7/12 Chris Frey <cd...@fo...>:
> On Tue, Jul 12, 2011 at 05:35:37PM -0400, Chris Frey wrote:
>> This format is used by the vformat plugin, in order to register
>> detector converters.  These detectors look inside plain data to
>> determine if it contains valid vformat data, such as vevents, etc.
>
> It looks like you (Luiz) are using the file sync plugin as a simplest
> case test case.
>
> I wonder if it is possible to disable all this detector / converter
> stuff, so that plain data remains plain data forevermore. :-)
>
> It seems that it could be a shocking development, if a person tries
> to sync, and somehow a binary blob that he is syncing, and that he
> assumes will never change (perhaps he sha1sums his file data),
> suddenly changes simply because it had vformat data, and went through
> the wash/rinse cycle of the xmlformat plugin.
>
> Daniel: Is is possible for the user to disable converter detectors?
> Is there any drawback to this that I'm not seeing?
>
> Thanks!
> - Chris
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>

Re: [Opensync-devel] Problem with conversions that use objtype data (like in file-sync)

[Chris F. <cd...@fo...>]

On Tue, Jul 12, 2011 at 05:35:37PM -0400, Chris Frey wrote:
> This format is used by the vformat plugin, in order to register
> detector converters.  These detectors look inside plain data to
> determine if it contains valid vformat data, such as vevents, etc.

It looks like you (Luiz) are using the file sync plugin as a simplest
case test case.

I wonder if it is possible to disable all this detector / converter
stuff, so that plain data remains plain data forevermore. :-)

It seems that it could be a shocking development, if a person tries
to sync, and somehow a binary blob that he is syncing, and that he
assumes will never change (perhaps he sha1sums his file data),
suddenly changes simply because it had vformat data, and went through
the wash/rinse cycle of the xmlformat plugin.

Daniel: Is is possible for the user to disable converter detectors?
Is there any drawback to this that I'm not seeing?

Thanks!
- Chris

Re: [Opensync-devel] Problem with conversions that use objtype data (like in file-sync)

[Chris F. <cd...@fo...>]

On Tue, Jul 12, 2011 at 04:47:37AM -0300, Luiz Angelo Daros de Luca wrote:
> Hello,
> 
> I'm getting a strange error on file-sync (and also in my ruby version
> of it) on a simple files-to-files test:
> 
> Main sink of member 1 of type file-sync had an error: Unable to find
> engine which can handle objtype data
> 
> According to http://www.opensync.org/wiki/glossary, "Conversion can
> change the format of an object but never its type."
> Is this still true?

I suspect it is not true.


> While debuging, I found out that file-sync, plain and the conversions
> between them (and also my ruby version of them), uses objtype =
> 'data'.
> 'data' must be some special wildcard objtype because its conversion
> matches my data defined as 'contact'.
> However at opensync/opensync/format/opensync_converter.c:222, it sets
> the data objtype to match the converter one.
> 
> 	osync_data_set_objtype(data,
> osync_objformat_get_objtype(converter->target_format));
> 
> The result is that data, after conversion, gets the correct format
> ('plain') but uses an incorrect objtype ('data').
> I guess the coverted data objtype should come from somewhere else,
> copying same objtype from the original data.
> 
> Who is wrong? opensync? file-sync? myself :-)?

It took a while, but I finally found the "plain"/"data" objformat
in the xmlformat plugin, in xmlformat_note_memo.c.  Ouch. :-)

This format is used by the vformat plugin, in order to register
detector converters.  These detectors look inside plain data to
determine if it contains valid vformat data, such as vevents, etc.

I *think*, that the detectors merely return yes/no as to whether a
plain format data object can be treated like the detector's target
format.

I've found something called "inverse" detectors, which have no detector
function.  I think the inverse detectors merely say that it is valid
to treat, for example, a vevent object as a plain, because there is a
converter available to convert it back.  This seems a bit flimsy, but
it seems that these detectors are only used for conversions to and from
plain/data objects.

So, in summary, I think it is possible for a contact to become a
plain/data and back.

- Chris

[Opensync-devel] Problem with conversions that use objtype data (like in file-sync)

[Luiz A. D. de L. <lui...@gm...>]

Hello,

I'm getting a strange error on file-sync (and also in my ruby version
of it) on a simple files-to-files test:

Main sink of member 1 of type file-sync had an error: Unable to find
engine which can handle objtype data

According to http://www.opensync.org/wiki/glossary, "Conversion can
change the format of an object but never its type."
Is this still true?

While debuging, I found out that file-sync, plain and the conversions
between them (and also my ruby version of them), uses objtype =
'data'.
'data' must be some special wildcard objtype because its conversion
matches my data defined as 'contact'.
However at opensync/opensync/format/opensync_converter.c:222, it sets
the data objtype to match the converter one.

	osync_data_set_objtype(data,
osync_objformat_get_objtype(converter->target_format));

The result is that data, after conversion, gets the correct format
('plain') but uses an incorrect objtype ('data').
I guess the coverted data objtype should come from somewhere else,
copying same objtype from the original data.

Who is wrong? opensync? file-sync? myself :-)?

Thanks,

---
     Luiz Angelo Daros de Luca, Me.
            lui...@gm...

Re: [Opensync-devel] python site-packages, debian, and opensync

[Chris F. <cd...@fo...>]

On Mon, Jul 11, 2011 at 09:32:31AM +0200, Bjoern Ricks wrote:
> Imho only debian changed the default installation. I couldn't find a PEP
> for site-package usage but e.g.
> http://docs.python.org/install/index.htmlexplicit mentions
> site-packages. Of course it is easy in python to change
> the include path via sys.path. For windows a PEP exists
> http://www.python.org/dev/peps/pep-0250/

Thanks.

As far as I could find, Debian actually patches site.py to rename
site-packages to dist-packages.  This changes any python program
that relies on site.py, automatically.  It still seems rather silly
to me to force site-packages when python itself is telling me
dist-packages.  Any normal system will tell me site-packages, as
normal.

Debian also adds the idea that the Filesystem Standard says that non-Debian
packages should install into /usr/local, and so Debian adds
/usr/local/.../dist-packages to the path as well, which takes
preceidence over the system paths.  This makes a lot of sense to
me, but not every system does this.

I think, in the end, your idea of adding a cmake override is best.
Even the ability to override which version of python to use would be
a good thing, I think.  That way it won't matter what default we use,
the compiling user can override it.  (as well as the packager.)

Do you have any comments or warnings that I should be careful about
if letting the user select which version of python to use?

- Chris

Re: [Opensync-devel] python site-packages, debian, and opensync

[Chris F. <cd...@fo...>]

On Sun, Jul 10, 2011 at 05:13:03PM +0200, Bjoern Ricks wrote:
> The official python way is to use site-packages.

Do you have a reference to this?  I was looking at the documentation,
and it seemed like it was all programmatic, and that distutils would
just use what the site admin had configured.

- Chris

Re: [Opensync-devel] python site-packages, debian, and opensync

[Bjoern R. <bjo...@go...>]

Am 05.07.11 22:28, schrieb Chris Frey:
> So does your hack for PYTHON_VERSION return the "current python" version?
>
> Have you submitted your new cmake module to the cmake guys?  It would
> be nice if this eventually was solved once and for all. :-)
Yes it does. It's a short patch and I'll try to create a cmake bug
report next week. I'll post it on opensync-devel too.

Regards,
Björn

Re: [Opensync-devel] python site-packages, debian, and opensync

[Bjoern R. <bjo...@go...>]

Hi Chris,

Am 05.07.11 23:16, schrieb Chris Frey:
> True, it is debian specific, and it would be nice to have this in the
> binary packaging.  But as far as I know, the new module won't
> work if I put it all by itself in an empty site-packages on Debian.
> It seems silly to go with site-packages, if I can get the real directory
> from python, like I'm doing now.
The official python way is to use site-packages. Therefore we should use
that directory too. They best way is to add a cmake variable to be able
to change the install dir via commandline. If not Debian could also add
a short and easy patch to use dist-packages.
> In reading docs.python.org, the "upstream method" is to use a setup.py to
> install and rely on Python's distutils.  But my patch is already using
> distutils (programmatically) to find the lib directory.  I'm not sure
> it is worth adding a setup.py for the opensync wrapper.  It would make
> it more official, I suppose.
Distutils aren't nice to handle for building libraries. Imho it lacks of
dependency management. Personally I did replace a setup.py installation
with cmake and it works much better then before. Therefore I would also
go for cmake instead of distutils.

Regards,
Björn

Re: [Opensync-devel] [PATCH]: rename plugin set_xxx callbacks to use _func suffix

[Chris F. <cd...@fo...>]

Hi Luiz,

I'm pinging this back on the mailing list, since we're discussing an
API change.

Thanks for the git repo link.  That's very helpful.

Have you tried compiling my binary-meta tree yet?  So far you need
a debian-style system for it to work completely.  It's a large compile,
but I think it would be good to use it as a test for any API changes
to the main library.  The more plugins I add over time, the more automatic
compile testing we get.

The patch looks sane.  You will want to change the opensync.sym symbol
list file as well.  Also note that opensync.sym is a sorted file.

Thanks!
- Chris


On Sun, Jul 03, 2011 at 10:22:47PM -0300, Luiz Angelo Daros de Luca wrote:
> Hello Chris,
> 
> I'm back online (back from FISL12). Maybe in the future I can present
> some stuff about opensync on it ;-)
> 
> git://github.com/luizluca/opensync-luizluca.git branch rename_plugin_callbacks
> 
> I also have some other branches on it that I might discuss in the
> future. I don't know how I could proceed with the plugin's code. The
> fix on them is trivial.
> 
> Feel free to comment the patch.
> 
> Regards,
> 
> ---
> ?? ???? Luiz Angelo Daros de Luca, Me.
> ?? ?? ?? ?? ?? ?? lui...@gm...
> 
> 
> 
> 2011/6/30 Chris Frey <cd...@fo...>:
> > Hi Luiz,
> >
> > Talk about dropping the ball on this one. ??Sorry about that.
> > Just getting to this now.
> >
> > Unfortunately, the patch is encoded as utf-8, and even when using
> > utf-8 here, git am complains.
> >
> > Seems to be using odd characters on the tabs, or the context lines of
> > the diff.
> >
> > Could you send the patch again, or even better, point me to your git
> > repo?
> >
> > Thanks
> > - Chris
> >
> >
> >
> > On Fri, Jun 10, 2011 at 03:10:53AM -0300, Luiz Angelo Daros de Luca wrote:
> >> Renames the methods that define plugin callbacks:
> >>
> >> osync_plugin_set_initialize??->??osync_plugin_set_initialize_func
> >> osync_plugin_set_finalize??->??osync_plugin_set_finalize_func
> >> osync_plugin_set_discover??->??osync_plugin_set_discover_func
> >>
> >> This makes the callback definition methods similar to the respective
> >> methods in plugin, format and sink.
> >>
> >>
> >> >From 625b78ba3888ed99235ff71a07e656f4b29d6909 Mon Sep 17 00:00:00 2001
> >> From: Luiz Angelo Daros de Luca <lui...@gm...>
> >> Date: Wed, 8 Jun 2011 03:34:45 -0300
> >> Subject: [PATCH 1/1] - Renamed osync_plugin_set_xxx callbacks function
> >> to use _func suffix
> >>
> >> Signed-off-by: Luiz Angelo Daros de Luca <lui...@gm...>
> >> ---
> >> ??docs/examples/plugins/src/external_demo.c ?? ?? ?? ?? ??| ?? ??6 ++--
> >> ??docs/examples/plugins/src/plugin.c ?? ?? ?? ?? ?? ?? ?? ?? | ?? ??6 ++--
> >> ??docs/examples/plugins/src/simple_plugin.c ?? ?? ?? ?? ??| ?? ??6 ++--
> >> ??.../plugins/src/simple_plugin_static_caps.c ?? ?? ?? ??| ?? ??6 ++--
> >> ??opensync/plugin/opensync_plugin.c ?? ?? ?? ?? ?? ?? ?? ?? ??| ?? ??6 ++--
> >> ??opensync/plugin/opensync_plugin.h ?? ?? ?? ?? ?? ?? ?? ?? ??| ?? ??6 ++--
> >> ??tests/engine-tests/check_engine.c ?? ?? ?? ?? ?? ?? ?? ?? ??| ?? 28 ++++++++++----------
> >> ??tests/engine-tests/check_engine_error.c ?? ?? ?? ?? ?? ??| ?? ??8 +++---
> >> ??tests/mock-plugin/mock_sync.c ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??| ?? ??6 ++--
> >> ??9 files changed, 39 insertions(+), 39 deletions(-)
> >> diff --git a/docs/examples/plugins/src/external_demo.c
> >> b/docs/examples/plugins/src/external_demo.c
> >> index adfbd5e..df59d6d 100644
> >> --- a/docs/examples/plugins/src/external_demo.c
> >> +++ b/docs/examples/plugins/src/external_demo.c
> >> @@ -122,9 +122,9 @@ int main(int argc, char **argv)
> >> ?? if (!plugin)
> >> ?? goto error;
> >>
> >> - osync_plugin_set_initialize(plugin, initialize);
> >> - osync_plugin_set_finalize(plugin, finalize);
> >> - osync_plugin_set_discover(plugin, discover);
> >> + osync_plugin_set_initialize_func(plugin, initialize);
> >> + osync_plugin_set_finalize_func(plugin, finalize);
> >> + osync_plugin_set_discover_func(plugin, discover);
> >>
> >>
> >> ?? /** Client */
> >> diff --git a/docs/examples/plugins/src/plugin.c
> >> b/docs/examples/plugins/src/plugin.c
> >> index eb3edb5..99dcdbf 100644
> >> --- a/docs/examples/plugins/src/plugin.c
> >> +++ b/docs/examples/plugins/src/plugin.c
> >> @@ -402,9 +402,9 @@ osync_bool get_sync_info(OSyncPluginEnv
> >> *pluginenv, OSyncError **error)
> >> ?? osync_plugin_set_description(plugin, "A longer description. < 200 chars");
> >>
> >> ?? //Now set the function we made earlier
> >> - osync_plugin_set_initialize(plugin, initialize);
> >> - osync_plugin_set_finalize(plugin, finalize);
> >> - osync_plugin_set_discover(plugin, discover);
> >> + osync_plugin_set_initialize_func(plugin, initialize);
> >> + osync_plugin_set_finalize_func(plugin, finalize);
> >> + osync_plugin_set_discover_func(plugin, discover);
> >>
> >> ?? if (!osync_plugin_env_register_plugin(pluginenv, plugin, error))
> >> ?? goto error;
> >> diff --git a/docs/examples/plugins/src/simple_plugin.c
> >> b/docs/examples/plugins/src/simple_plugin.c
> >> index 0b37770..313d859 100644
> >> --- a/docs/examples/plugins/src/simple_plugin.c
> >> +++ b/docs/examples/plugins/src/simple_plugin.c
> >> @@ -322,9 +322,9 @@ osync_bool get_sync_info(OSyncPluginEnv *env,
> >> OSyncError **error)
> >> ?? osync_plugin_set_description(plugin, "A longer description. < 200 chars");
> >>
> >> ?? //Now set the function we made earlier
> >> - osync_plugin_set_initialize(plugin, initialize);
> >> - osync_plugin_set_finalize(plugin, finalize);
> >> - osync_plugin_set_discover(plugin, discover);
> >> + osync_plugin_set_initialize_func(plugin, initialize);
> >> + osync_plugin_set_finalize_func(plugin, finalize);
> >> + osync_plugin_set_discover_func(plugin, discover);
> >>
> >> ?? if (!osync_plugin_env_register_plugin(env, plugin, error))
> >> ?? goto error;
> >> diff --git a/docs/examples/plugins/src/simple_plugin_static_caps.c
> >> b/docs/examples/plugins/src/simple_plugin_static_caps.c
> >> index c70847d..091fcfc 100644
> >> --- a/docs/examples/plugins/src/simple_plugin_static_caps.c
> >> +++ b/docs/examples/plugins/src/simple_plugin_static_caps.c
> >> @@ -321,9 +321,9 @@ osync_bool get_sync_info(OSyncPluginEnv *env,
> >> OSyncError **error)
> >> ?? osync_plugin_set_description(plugin, "A longer description. < 200 chars");
> >>
> >> ?? //Now set the function we made earlier
> >> - osync_plugin_set_initialize(plugin, initialize);
> >> - osync_plugin_set_finalize(plugin, finalize);
> >> - osync_plugin_set_discover(plugin, discover);
> >> + osync_plugin_set_initialize_func(plugin, initialize);
> >> + osync_plugin_set_finalize_func(plugin, finalize);
> >> + osync_plugin_set_discover_func(plugin, discover);
> >>
> >> ?? if (!osync_plugin_env_register_plugin(env, plugin, error))
> >> ?? goto error;
> >> diff --git a/opensync/plugin/opensync_plugin.c
> >> b/opensync/plugin/opensync_plugin.c
> >> index b22200d..3afb93a 100644
> >> --- a/opensync/plugin/opensync_plugin.c
> >> +++ b/opensync/plugin/opensync_plugin.c
> >> @@ -165,20 +165,20 @@ void osync_plugin_set_start_type(OSyncPlugin
> >> *plugin, OSyncStartType start_type)
> >> ?? plugin->start_type = start_type;
> >> ??}
> >>
> >> -void osync_plugin_set_initialize(OSyncPlugin *plugin, initialize_fn init)
> >> +void osync_plugin_set_initialize_func(OSyncPlugin *plugin, initialize_fn init)
> >> ??{
> >> ?? osync_assert(plugin);
> >> ?? plugin->initialize = init;
> >> ??}
> >>
> >> -void osync_plugin_set_finalize(OSyncPlugin *plugin, finalize_fn fin)
> >> +void osync_plugin_set_finalize_func(OSyncPlugin *plugin, finalize_fn fin)
> >> ??{
> >> ?? osync_assert(plugin);
> >>
> >> ?? plugin->finalize = fin;
> >> ??}
> >>
> >> -void osync_plugin_set_discover(OSyncPlugin *plugin, discover_fn discover)
> >> +void osync_plugin_set_discover_func(OSyncPlugin *plugin, discover_fn discover)
> >> ??{
> >> ?? osync_assert(plugin);
> >> ?? plugin->discover = discover;
> >> diff --git a/opensync/plugin/opensync_plugin.h
> >> b/opensync/plugin/opensync_plugin.h
> >> index dcfb19e..2ce79e3 100644
> >> --- a/opensync/plugin/opensync_plugin.h
> >> +++ b/opensync/plugin/opensync_plugin.h
> >> @@ -210,7 +210,7 @@ OSYNC_EXPORT void
> >> osync_plugin_set_description(OSyncPlugin *plugin, const char *
> >> ?? * @param plugin Pointer to the plugin
> >> ?? * @param init The initialize function for the plugin
> >> ?? */
> >> -OSYNC_EXPORT void osync_plugin_set_initialize(OSyncPlugin *plugin,
> >> initialize_fn init);
> >> +OSYNC_EXPORT void osync_plugin_set_initialize_func(OSyncPlugin
> >> *plugin, initialize_fn init);
> >>
> >> ??/** @brief Sets the finalize function for a plugin
> >> ?? *
> >> @@ -220,7 +220,7 @@ OSYNC_EXPORT void
> >> osync_plugin_set_initialize(OSyncPlugin *plugin, initialize_fn
> >> ?? * @param plugin Pointer to the plugin
> >> ?? * @param fin The finalize function for the plugin
> >> ?? */
> >> -OSYNC_EXPORT void osync_plugin_set_finalize(OSyncPlugin *plugin,
> >> finalize_fn fin);
> >> +OSYNC_EXPORT void osync_plugin_set_finalize_func(OSyncPlugin *plugin,
> >> finalize_fn fin);
> >>
> >> ??/** @brief Sets the optional discover function for a plugin
> >> ?? *
> >> @@ -234,7 +234,7 @@ OSYNC_EXPORT void
> >> osync_plugin_set_finalize(OSyncPlugin *plugin, finalize_fn fin
> >> ?? * @param plugin Pointer to the plugin
> >> ?? * @param discover The discover function for the plugin
> >> ?? */
> >> -OSYNC_EXPORT void osync_plugin_set_discover(OSyncPlugin *plugin,
> >> discover_fn discover);
> >> +OSYNC_EXPORT void osync_plugin_set_discover_func(OSyncPlugin *plugin,
> >> discover_fn discover);
> >>
> >>
> >> ??/** @brief Returns the plugin_info data, set by the plugin
> >> diff --git a/tests/engine-tests/check_engine.c
> >> b/tests/engine-tests/check_engine.c
> >> index b7cb9e5..03bf2e8 100644
> >> --- a/tests/engine-tests/check_engine.c
> >> +++ b/tests/engine-tests/check_engine.c
> >> @@ -289,8 +289,8 @@ static OSyncDebugGroup *_create_group(char *testbed)
> >> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>
> >> - osync_plugin_set_initialize(debug->plugin, initialize);
> >> - osync_plugin_set_finalize(debug->plugin, finalize);
> >> + osync_plugin_set_initialize_func(debug->plugin, initialize);
> >> + osync_plugin_set_finalize_func(debug->plugin, finalize);
> >>
> >> ?? debug->client1 = osync_client_new(&error);
> >> ?? fail_unless(debug->client1 != NULL, NULL);
> >> @@ -636,8 +636,8 @@ static OSyncDebugGroup *_create_group2(char *testbed)
> >> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>
> >> - osync_plugin_set_initialize(debug->plugin, initialize_multi);
> >> - osync_plugin_set_finalize(debug->plugin, finalize_multi);
> >> + osync_plugin_set_initialize_func(debug->plugin, initialize_multi);
> >> + osync_plugin_set_finalize_func(debug->plugin, finalize_multi);
> >>
> >> ?? debug->client1 = osync_client_new(&error);
> >> ?? fail_unless(debug->client1 != NULL, NULL);
> >> @@ -1037,8 +1037,8 @@ static OSyncDebugGroup *_create_group3(char *testbed)
> >> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>
> >> - osync_plugin_set_initialize(debug->plugin, initialize_order);
> >> - osync_plugin_set_finalize(debug->plugin, finalize_order);
> >> + osync_plugin_set_initialize_func(debug->plugin, initialize_order);
> >> + osync_plugin_set_finalize_func(debug->plugin, finalize_order);
> >>
> >>
> >> ?? debug->client1 = osync_client_new(&error);
> >> @@ -1271,8 +1271,8 @@ static OSyncDebugGroup *_create_group4(char *testbed)
> >> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>
> >> - osync_plugin_set_initialize(debug->plugin, initialize_reuse);
> >> - osync_plugin_set_finalize(debug->plugin, finalize_reuse);
> >> + osync_plugin_set_initialize_func(debug->plugin, initialize_reuse);
> >> + osync_plugin_set_finalize_func(debug->plugin, finalize_reuse);
> >>
> >> ?? debug->client1 = osync_client_new(&error);
> >> ?? fail_unless(debug->client1 != NULL, NULL);
> >> @@ -1550,8 +1550,8 @@ static OSyncDebugGroup *_create_group5(char *testbed)
> >> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>
> >> - osync_plugin_set_initialize(debug->plugin, initialize5);
> >> - osync_plugin_set_finalize(debug->plugin, finalize5);
> >> + osync_plugin_set_initialize_func(debug->plugin, initialize5);
> >> + osync_plugin_set_finalize_func(debug->plugin, finalize5);
> >>
> >> ?? debug->client1 = osync_client_new(&error);
> >> ?? fail_unless(debug->client1 != NULL, NULL);
> >> @@ -1758,8 +1758,8 @@ static OSyncDebugGroup *_create_group6(char *testbed)
> >> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>
> >> - osync_plugin_set_initialize(debug->plugin, initialize6);
> >> - osync_plugin_set_finalize(debug->plugin, finalize6);
> >> + osync_plugin_set_initialize_func(debug->plugin, initialize6);
> >> + osync_plugin_set_finalize_func(debug->plugin, finalize6);
> >>
> >> ?? debug->client1 = osync_client_new(&error);
> >> ?? fail_unless(debug->client1 != NULL, NULL);
> >> @@ -1961,8 +1961,8 @@ static OSyncDebugGroup *_create_group7(char *testbed)
> >> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>
> >> - osync_plugin_set_initialize(debug->plugin, initialize7);
> >> - osync_plugin_set_finalize(debug->plugin, finalize7);
> >> + osync_plugin_set_initialize_func(debug->plugin, initialize7);
> >> + osync_plugin_set_finalize_func(debug->plugin, finalize7);
> >>
> >> ?? debug->client1 = osync_client_new(&error);
> >> ?? fail_unless(debug->client1 != NULL, NULL);
> >> diff --git a/tests/engine-tests/check_engine_error.c
> >> b/tests/engine-tests/check_engine_error.c
> >> index 4eb3f1d..6dd8b40 100644
> >> --- a/tests/engine-tests/check_engine_error.c
> >> +++ b/tests/engine-tests/check_engine_error.c
> >> @@ -210,8 +210,8 @@ static OSyncDebugGroup *_create_group5(char *testbed)
> >> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>
> >> - osync_plugin_set_initialize(debug->plugin, initialize_connect_error);
> >> - osync_plugin_set_finalize(debug->plugin, finalize);
> >> + osync_plugin_set_initialize_func(debug->plugin, initialize_connect_error);
> >> + osync_plugin_set_finalize_func(debug->plugin, finalize);
> >>
> >>
> >> ?? debug->plugin2 = osync_plugin_new(&error);
> >> @@ -223,8 +223,8 @@ static OSyncDebugGroup *_create_group5(char *testbed)
> >> ?? osync_plugin_set_description(debug->plugin2, "This is a pseudo plugin");
> >> ?? osync_plugin_set_start_type(debug->plugin2, OSYNC_START_TYPE_EXTERNAL);
> >>
> >> - osync_plugin_set_initialize(debug->plugin2, initialize_connect_error);
> >> - osync_plugin_set_finalize(debug->plugin2, finalize);
> >> + osync_plugin_set_initialize_func(debug->plugin2, initialize_connect_error);
> >> + osync_plugin_set_finalize_func(debug->plugin2, finalize);
> >>
> >>
> >> ?? debug->client1 = osync_client_new(&error);
> >> diff --git a/tests/mock-plugin/mock_sync.c b/tests/mock-plugin/mock_sync.c
> >> index ecdde36..78f3c32 100644
> >> --- a/tests/mock-plugin/mock_sync.c
> >> +++ b/tests/mock-plugin/mock_sync.c
> >> @@ -794,9 +794,9 @@ osync_bool get_sync_info(OSyncPluginEnv *env,
> >> OSyncError **error)
> >> ?? osync_plugin_set_description(plugin, "Plugin to synchronize files on
> >> the local filesystem for unit tests");
> >> ?? osync_plugin_set_start_type(plugin, OSYNC_START_TYPE_EXTERNAL);
> >>
> >> - osync_plugin_set_initialize(plugin, mock_initialize);
> >> - osync_plugin_set_finalize(plugin, mock_finalize);
> >> - osync_plugin_set_discover(plugin, mock_discover);
> >> + osync_plugin_set_initialize_func(plugin, mock_initialize);
> >> + osync_plugin_set_finalize_func(plugin, mock_finalize);
> >> + osync_plugin_set_discover_func(plugin, mock_discover);
> >>
> >> ?? if (!osync_plugin_env_register_plugin(env, plugin, error))
> >> ?? goto error;
> >> --
> >> 1.7.4.1
> >>
> >> ------------------------------------------------------------------------------
> >> EditLive Enterprise is the world's most technically advanced content
> >> authoring tool. Experience the power of Track Changes, Inline Image
> >> Editing and ensure content is compliant with Accessibility Checking.
> >> http://p.sf.net/sfu/ephox-dev2dev
> >> _______________________________________________
> >> Opensync-devel mailing list
> >> Ope...@li...
> >> https://lists.sourceforge.net/lists/listinfo/opensync-devel
> >
> > ------------------------------------------------------------------------------
> > All of the data generated in your IT infrastructure is seriously valuable.
> > Why? It contains a definitive record of application performance, security
> > threats, fraudulent activity, and more. Splunk takes this data and makes
> > sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Opensync-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensync-devel
> >

Re: [Opensync-devel] python site-packages, debian, and opensync

[Chris F. <cd...@fo...>]

On Tue, Jul 05, 2011 at 01:07:43AM +0200, Michael Banck wrote:
> > > Ubuntu and Debian have packaged python2.6 so that such modules are
> > > installed into /usr/lib/python2.6/dist-packages instead of site-packages.
> > > site-packages is not in the default path, as far as I know.
> >
> > Imho that is a debian only change but I am not sure. Maybe Michael Bank
> > (azeem) knows the details. Normally I would install the python module in
> > /usr/lib/python${PYTHON_VERSION}/site-packages. But we should add a
> > possibility to set that path at cmake runtime. In debian I have also
> > seen a /usr/lib/pymodules and /usr/lib/pyshared directories ...
> 
> I haven't looked into it in detail, but in general, I think opensync
> should do what is recommended upstream, and any Debian/Ubuntu-specific
> things should handled in the Debian packaging.

True, it is debian specific, and it would be nice to have this in the
binary packaging.  But as far as I know, the new module won't
work if I put it all by itself in an empty site-packages on Debian.
It seems silly to go with site-packages, if I can get the real directory
from python, like I'm doing now.

In reading docs.python.org, the "upstream method" is to use a setup.py to
install and rely on Python's distutils.  But my patch is already using
distutils (programmatically) to find the lib directory.  I'm not sure
it is worth adding a setup.py for the opensync wrapper.  It would make
it more official, I suppose.

- Chris

Re: [Opensync-devel] python site-packages, debian, and opensync

[Chris F. <cd...@fo...>]

On Sun, Jul 03, 2011 at 02:00:51PM +0200, Bjoern Ricks wrote:
> I think its the right approach to drop our own cmake files which are
> included upstream now. Please don't forget to set the correct
> cmake_minimum_required version.

Thanks.  So far I've been setting it to version 2.6.


> Funny I did just hacked the original cmake FindPythonLibs and
> FindPythonInterp some days ago :-) Imho they aren't working correctly
> and are missing indeed a PYTHON_VERSION variable which I did add also.
> The problem with these files is that they are searching for the newest
> python installation (up to python 2.7) and not for the current version
> in use. E.g. you could have installed python 2.4, 2.5 and 2.6 then it
> would use python 2.6 for all path independent of which version you are
> currently using. That means that it could be possible that the created
> python module will not be available for your currently python version
> but only for the newest installed one.

So does your hack for PYTHON_VERSION return the "current python" version?

Have you submitted your new cmake module to the cmake guys?  It would
be nice if this eventually was solved once and for all. :-)

- Chris

Re: [Opensync-devel] python site-packages, debian, and opensync

[Michael B. <mb...@de...>]

On Sun, Jul 03, 2011 at 02:00:51PM +0200, Bjoern Ricks wrote:
> Am 01.07.11 05:48, schrieb Chris Frey:
> > The problem:
> > ------------
> >
> > Our FindPythonLibs.cmake was hacked to add PYTHON_VERSION.  It basically
> > called python and asked for its version number.  Simple enough.
> Which is really necessary and needed in many cases.
> >
> > I could copy that into the main wrapper/CMakeLists.txt, but there's another
> > issue.
> >
> > Ubuntu and Debian have packaged python2.6 so that such modules are
> > installed into /usr/lib/python2.6/dist-packages instead of site-packages.
> > site-packages is not in the default path, as far as I know.
> Imho that is a debian only change but I am not sure. Maybe Michael Bank
> (azeem) knows the details. Normally I would install the python module in
> /usr/lib/python${PYTHON_VERSION}/site-packages. But we should add a
> possibility to set that path at cmake runtime. In debian I have also
> seen a /usr/lib/pymodules and /usr/lib/pyshared directories ...

I haven't looked into it in detail, but in general, I think opensync
should do what is recommended upstream, and any Debian/Ubuntu-specific
things should handled in the Debian packaging.


Michael

Re: [Opensync-devel] missing code in opensync_obj_engine.c

[Chris F. <cd...@fo...>]

On Sat, Jul 02, 2011 at 12:16:25PM +0200, Daniel Gollub wrote:
> I guess you have some trouble with your GNOME keyring - Password for '(null)' 
> doesn't soudn right ...

Yeah, that was the problem.  I had recently upgraded to Debian Squeeze,
and there must be some funky new keyring stuff going on. :-)

The solution was adding the following to ~/.subversion/config

[auth]
password-stores =

Thanks,
- Chris

Re: [Opensync-devel] python site-packages, debian, and opensync

[Bjoern R. <bjo...@go...>]

Hi Chris,

Am 01.07.11 05:48, schrieb Chris Frey:
> Hi,
>
> I'm not a python guy, so I'm looking for feedback.
>
> Background:
> -----------
>
> I'm working on binary packaging and the opensync and plugin source
> trees, in order to clean up duplication.  To that end, I'm working
> on removing as many cmake modules that are now officially in cmake.
> Less code to audit on our side if we can rely on cmake itself.
I think its the right approach to drop our own cmake files which are
included upstream now. Please don't forget to set the correct
cmake_minimum_required version.
>
> Unfortunately, some of our cmake modules have been hacked to add
> special features.  In my opinion, these hacks belong in our own
> CMakeLists.txt, not in our own copies of files like FindPythonLibs.cmake.
> This way we easily know which is our code, and which is theirs.
Funny I did just hacked the original cmake FindPythonLibs and
FindPythonInterp some days ago :-) Imho they aren't working correctly
and are missing indeed a PYTHON_VERSION variable which I did add also.
The problem with these files is that they are searching for the newest
python installation (up to python 2.7) and not for the current version
in use. E.g. you could have installed python 2.4, 2.5 and 2.6 then it
would use python 2.6 for all path independent of which version you are
currently using. That means that it could be possible that the created
python module will not be available for your currently python version
but only for the newest installed one.
>
>
> The problem:
> ------------
>
> Our FindPythonLibs.cmake was hacked to add PYTHON_VERSION.  It basically
> called python and asked for its version number.  Simple enough.
Which is really necessary and needed in many cases.
>
> I could copy that into the main wrapper/CMakeLists.txt, but there's another
> issue.
>
> Ubuntu and Debian have packaged python2.6 so that such modules are
> installed into /usr/lib/python2.6/dist-packages instead of site-packages.
> site-packages is not in the default path, as far as I know.
Imho that is a debian only change but I am not sure. Maybe Michael Bank
(azeem) knows the details. Normally I would install the python module in
/usr/lib/python${PYTHON_VERSION}/site-packages. But we should add a
possibility to set that path at cmake runtime. In debian I have also
seen a /usr/lib/pymodules and /usr/lib/pyshared directories ...
>
> So to properly install our wrapper module into an official path, we now
> need to know what the whole path name is, not just the version.
>
> This is my attempt at implementing this feature:
>
> http://repo.or.cz/w/opensync/opensync-cdf.git/commit/0ab5a7e597e8771b5a77a6070e78619bbca8fc9c
>
>
> The question:
> -------------
>
> My question to python experts: is it right for opensync to install into
> dist-packages?  In our debian binary packages, we will indeed want to install
> into dist-packages, but from a source perspective, I'm not sure.  The
> user should be installing to /usr/local/lib/dist-packages in that case,
> and with the right cmake prefix, this will work fine.
>
> Please let me know if you see any gotcha's with the plan.
>
> Thanks,
> - Chris

[Opensync-devel] Patch for evolution plugin

[Ian M. <ian...@ca...>]

Hi,

On 2 July 2011 16:42, Nicolas <pr...@fr...> wrote:
> Le samedi 02 juillet 2011 à 12:27 +0200, Daniel Gollub a écrit :
>> Hi Nicolas,
>>
>> On Saturday, July 02, 2011 08:06:40 am Nicolas wrote:
>> > With this patch, it works with new Evolution release 2.32 and higher.
>>
>> Could you explain which change was exactly required to get it working again for 2.32? It's hard
>> for me to distinguish the diff between the new feature and the required change to make it work.
>
> It's an old patch ; that I have forgotten to send you.
>
> It's the API that is different with 2.32 :

The current code seems to work fine for me with 2.32

> With this modification, opensync can find the good address book ;
> otherwise it finds nothing.
>
>
>> > Moreover, I have added an option to be able to choose the evolution
>> > addressbook, calendar, tasks or memo  to sync.
>> [...]

I don't think this patch does anything new. The plugin has been able
to choose addressbook/calendar by name or uri for a while.

The <url></url> field can be one of 3 options
1) "default" is a special value that opens the default
addressbook/calendar, etc (you can set an item as the default using
evolution)
2) A uri such as "local:system" or google://example@gmail.com
3) The name of the addressbook/calendar, etc

This is why the uri is also compared to the name in the second strcmp
in evo2_find_source:
 if (!strcmp(e_source_peek_name(source), uri))

Using this method has it's problems if you name an entry "default" or
"local:system", so perhaps the <url> field should be an option of:
<default />
<url></url>
<name></name>
to avoid mismatches but the current method seems simple to use.

There are some short bad docs on the wiki at
http://www.opensync.org/wiki/trunk/syncing/evolution

Hope that makes sense,

Ian

Re: [Opensync-devel] Patch for evolution plugin

[Nicolas <pr...@fr...>]

Le samedi 02 juillet 2011 à 12:27 +0200, Daniel Gollub a écrit :
> Hi Nicolas,
> 
> On Saturday, July 02, 2011 08:06:40 am Nicolas wrote:
> > With this patch, it works with new Evolution release 2.32 and higher.
> 
> Could you explain which change was exactly required to get it working again for 2.32? It's hard 
> for me to distinguish the diff between the new feature and the required change to make it work.

It's an old patch ; that I have forgotten to send you.

It's the API that is different with 2.32 :

In src/evolution2_sync.c:

  -           osync_trace(TRACE_INTERNAL, "Comparing source name %s and
%s", e_source_peek_name(source), uri);
  -           if (!strcmp(e_source_peek_name(source), uri))
  +           osync_trace(TRACE_INTERNAL, "Comparing source name %s and
%s", e_source_peek_name(source), book);
  +           if (!strcmp(e_source_peek_name(source), book))


My modification works with old Evolution release. But to check !

With this modification, opensync can find the good address book ;
otherwise it finds nothing.

 
> > Moreover, I have added an option to be able to choose the evolution
> > addressbook, calendar, tasks or memo  to sync.
> [...]
> 
> Nice!
> 
> One more question:
> 
> ---8<--
> @@ -88,7 +90,7 @@
>          osync_trace(TRACE_ENTRY, "%s(%p, %p, %p, %p)", __func__, sink, info, ctx, userdata);
>   	OSyncEvoCalendar * evo_cal = (OSyncEvoCalendar *)userdata;
>  
> -	if (!(evo_cal->calendar = evo2_ecal_open_cal(evo_cal->uri, evo_cal->source_type, &error))) {
> +	if (!(evo_cal->calendar = evo2_ecal_open_cal(evo_cal->uri, "Personnel", evo_cal->source_type, 
> &error))) {
>  		goto error;
>  	}
> ---8<---
> 
> In this diff hunk you set "Personnel" - is this hardcoded string intended at this place?

Sorry an error...

Should be as for address book.

> 
> > 
> > <Name>....</Name> : it's to select the good entry in evolution.
> > 
> > (idem for calendar, memo and tasks)
> 
> Do you know if the <Name/> value is language dependent in evoulation?
> If so, do you know any language indepenent good default value?
> You wrote in the default configuration "Personnal" in the plugin-code "Personnel".

Yes, it depends on the evolution language.

So, I hardcoded in the default configuration the english name.

We can add comments into the default file.

> Best Regards,
> Daniel

Regards,

Nicolas