[trunk] OSYNC_START_TYPE_EXTERNAL example / OSyncClient API changes

[Daniel Gollub-3]

Hi,


finally we have an example implementation for OSYNC_START_TYPE_EXTERNAL.

What this OSYNC_START_TYPE_EXTERNAL about?

This allows to write (standalone) userspace applications which act as OpenSync
plugin. You can use this for example if you try to gather data from an
existing application, which doesn't provides any public interface - e.g. an
extension of an application which communicates with OpenSync.

Currently, there is need of stub plugin, which registers the plugin to the
OpenSync environment. As Graham already suggested in a seperated thread, we'll
very likely change it - so there is only need to write a simple configuration
file to register external plugins.

Additionally we'll add some configuration options so OpenSync can spawn such
external process if they haven't be launced yet. For now such applications
have to be started manually ...

See:
http://opensync.org/browser/trunk/docs/examples/plugins/src/external_demo.c
and
http://opensync.org/changeset/5895

-------8<-------
$ ./example_external_demo ~/.config/opensync/0.40/group6/1/pluginpipe &
[1] 10841
$
[EXTERNAL-DEMO]: OSyncPlugin:0x40159d OSyncClient:0x603040
[EXTERNAL-DEMO]: Starting (blocking) OSyncClient ...
$
$ osynctool --sync external
Synchronizing group "external"
[EXTERNAL-DEMO]: initialize
data sink of member 2 of type file-sync just connected
Main sink of member 2 of type file-sync just connected
data sink of member 1 of type external-demo just connected
Main sink of member 1 of type external-demo just connected
All clients connected or error
[EXTERNAL-DEMO]: get_changes slow_sync: no
data sink of member 2 of type file-sync just sent all changes
data sink of member 1 of type external-demo just sent all changes
Main sink of member 1 of type external-demo just sent all changes
Main sink of member 2 of type file-sync just sent all changes
[...]
The sync was successful
data sink of member 1 of type external-demo just disconnected
Main sink of member 1 of type external-demo just disconnected
data sink of member 2 of type file-sync just disconnected
Main sink of member 2 of type file-sync just disconnected
All clients have disconnected
[EXTERNAL-DEMO]: OSyncClient completed.
[1]+ Done ./example_external_demo ~/.config/opensync/0.40/group6/1/pluginpipe
$
-------->8-----------

This required changes on the OSyncClient API:

osync_client_{get,set}_{plugin,pipe_path} got added to the public API. Which
are used to write an external plugin (see reference implementation).

An public interface which shouldn't be widely used yet got changed:
osync_client_run_and_block() got an additional parameter (OSyncError **) and
changed the return value from void to osync_bool. (Should be very trivial to
port).

If there are any questions regarding this changes, don't hesistate to ask on
the opensync-devel Mailinglist.

Thanks to Henrik and Graham for their feedback and help to get this working!

Best Regards,
Daniel

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Henrik /KaarPoSoft-2]

Great!

Thanks a lot Daniel.
Works like a charm!

/Henrik


Daniel Gollub wrote:
> Hi,
>
>
> finally we have an example implementation for OSYNC_START_TYPE_EXTERNAL.
>
> [...]

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Graham Cobb-4]

On Friday 30 October 2009 21:49:22 Daniel Gollub wrote:
> Currently, there is need of stub plugin, which registers the plugin to the
> OpenSync environment. As Graham already suggested in a seperated thread,
> we'll very likely change it - so there is only need to write a simple
> configuration file to register external plugins.

I have a first cut of the external plugin config file ready to check in
(http://opensync.pastebin.com/m38d98a95).  But I have a couple of questions:

1) When I run the unittests, 17 of them fail.  I don't *think* any of them are
related to these changes but is that expected at the moment?

The following tests FAILED:
         36 - filter_sync_deny_all (Failed)
        176 - lock_dual_sync_engine_lock (Failed)
        206 - mapping_engine_same_similar_conflict (Failed)
        207 - mapping_engine_same_similar_conflict2 (Failed)
        208 - mapping_engine_same_similar_conflict_multi (Failed)
        227 - multisync_dual_new (Failed)
        228 - multisync_triple_new (Failed)
        239 - multisync_conflict_data_duplicate (Failed)
        240 - multisync_conflict_data_duplicate2 (Failed)
        246 - sync_easy_conflict (Failed)
        247 - sync_easy_new_mapping (Failed)
        248 - sync_easy_conflict_duplicate (Failed)
        249 - sync_easy_conflict_abort (Failed)
        250 - sync_conflict_duplicate2 (Failed)
        251 - sync_conflict_delay (Failed)
        256 - sync_large (Failed)
        261 - sync_initial_slow_sync (Failed)

If it is not expected I will have to do some more checking.

2) I have created an example external plugin config file in
docs/examples/plugins/src.  Can the existing CMake macros be used to get that
file installed into the plugin directory (which is where I am looking for
it -- I look for .xml files first, then .so files)?  I haven't tried it but I
assume the macros like OPENSYNC_PLUGIN_INSTALL expect a .so file.

I really don't know CMake -- can anyone advise how to get my .xml file
installed into the plugin directory?

The new code seems to work but there are a few things that still need to be
done:

3) The XML format includes <ExternalCommand> but I currently ignore it.  My
plan is that this should be saved in the plugin structure and could be used
as a default for the config option that Henrik is adding.

4) If the .xml and the .so are both present, they both get loaded and two
plugins exist with the same name.  I thought of adding error checking to  
osync_plugin_set_name to fail if a plugin of the same name is already loaded.  
But I have just noticed that none of the osync_plugin_set_... calls have
OSyncError parameters.  Should they?  This would be an API change (to a
widely used API).

5) There is no unittest for this code yet.

I'm not sure if I will get time to work on this further on Sunday -- I will
check it in by the end of Sunday.

Graham

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Sunday 01 November 2009 01:39:24 am Graham Cobb wrote:
> I have a first cut of the external plugin config file ready to check in
> (http://opensync.pastebin.com/m38d98a95).


Thanks, will review your patch ASAP!


> But I have a couple of
>  questions:
>
> 1) When I run the unittests, 17 of them fail.  I don't think any of them
>  are  related to these changes but is that expected at the moment?

No, actually they should fail.

Could you run: "make Experimental" so the testing resutls get uploaded to the
CDash dashboard .. so we can have a look on the logs?


http://opensync.org/testing/index.php?project=OpenSync



>
> The following tests FAILED:
[...]


JFYI, you can also run those tests with:

ctest -V

-V makes things more verbose ...

If you only want to run specific tests you can use -R $regex to run only
specifc tests - e.g.:

ctest -V -R sync_

Will run all tests including "sync_"

>
> If it is not expected I will have to do some more checking.

Would be great if you could check whats going wrong there ...
Those tests also fail if you revert your changes - right?

>
> 2) I have created an example external plugin config file in
> docs/examples/plugins/src.  Can the existing CMake macros be used to get
>  that  file installed into the plugin directory (which is where I am
>  looking for it -- I look for .xml files first, then .so files)?  I haven't
>  tried it but I assume the macros like OPENSYNC_PLUGIN_INSTALL expect a .so
>  file.

OSYNC_PLUGIN_INSTALL is quite simple ... it doesn't check for *.so

-----8<----
## Install plugin
MACRO( OPENSYNC_PLUGIN_INSTALL _pluginName )
  INSTALL( TARGETS ${_pluginName} DESTINATION ${OPENSYNC_PLUGINDIR} )
ENDMACRO( OPENSYNC_PLUGIN_INSTALL )
---->8------

So you could point this to a .xml file ... but maybe we should introduce a new
macro for such configuration file. Maybe one day we want to change the
location of this kind config file .. so we just need to change the central
macro, and don't have to fix all plugins. What do you think?

>
> I really don't know CMake -- can anyone advise how to get my .xml file
> installed into the plugin directory?

I'll introduce a cmake macro called "OPENSYNC_EXTERNAL_PLUGIN_INSTALL" ...


>
> The new code seems to work but there are a few things that still need to
>  be  done:
>
> 3) The XML format includes <ExternalCommand> but I currently ignore
>  it.  My  plan is that this should be saved in the plugin structure and
>  could be used as a default for the config option that Henrik is adding.

Ok, fine with me.

>
> 4) If the .xml and the .so are both present, they both get loaded and two
> plugins exist with the same name.  I thought of adding error checking to  
> osync_plugin_set_name to fail if a plugin of the same name is already
>  loaded.   But I have just noticed that none of the osync_plugin_set_...
>  calls have OSyncError parameters.  Should they?  This would be an API
>  change (to a widely used API).

Actually the file-name of a plugin doesn't have to be the name of the plugin
in the Plugin Enviroment. e.g.: syncml.so spawns 4 plugins, non called
"syncml".

But i see your point with osync_plugin_set_name() .. and having multiple
plugins with the same name. This problem is already present ... even without
your modification.

What we could do, without breaking the api to handle this:

We could let osync_plugin_env_load() fail if there are multiple plugins with
the same name in the env->plugins list. Or we could let
osync_plugin_env_register_plugin() fail ... but this function get called by
the plugins any maybe not get handled by the plugin. We could do checks in
both function to be sure ...

Anyway, this is a different issue - independent of your planned changes ..
which should get fixed at some point. I'll create for that a ticket ... in my
opionoen it's not a blocker, since this could be avoided by distribution with
sane packaging ;)

>
> 5) There is no unittest for this code yet.
>
> I'm not sure if I will get time to work on this further on Sunday -- I
>  will  check it in by the end of Sunday.
>

Ok, cool. Thanks for your contribution!

Best Regards,
Daniel


--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Sunday 01 November 2009 01:39:24 am Graham Cobb wrote:
> I have a first cut of the external plugin config file ready to check in
> (http://opensync.pastebin.com/m38d98a95).  But I have a couple of
>  questions:
>

------8<-----
@@ -69,9 +71,8 @@
                        env->plugins = osync_list_remove(env->plugins, env-
>plugins->data);
                }

-               /* Unload all modules */
+               /* Unref (and so unload) all modules */
                while (env->modules) {
-                       osync_module_unload(env->modules->data);
                        osync_module_unref(env->modules->data);
                        env->modules = osync_list_remove(env->modules, env-
>modules->data);
                }
----->8----

Is the drop of osync_module_unload() intended?



---------8<----------
@@ -117,6 +119,31 @@
[...]
+               if (!osync_plugin_env_load_module_xml(env, filename, error)) {
+                       osync_trace(TRACE_ERROR, "Unable to load module: %s",
osync_error_print(error));
+               }
+              
+               osync_free(filename);
[...]
---------->8--------------

You ignore the error, like it was done for the loading the shared-module
plugins - right? Or is there any specific reason for that?

We should place here (and for the same place for shared-modules loading) a
FIXME .. since we're leaking here a OSyncError-struct if an error get set.
And also problems of loading a plugin is not visible as long you don't look
into trace-files  ... but that shouldn't block to apply your patch. I'll
create a ticket for that issue ...


Beside that this looks pretty perfect to me. I'll write a XSD (XML-Schema)
for your XML file.

Best Regards,
Daniel

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Sunday 01 November 2009 01:39:24 am Graham Cobb wrote:
> 3) The XML format includes <ExternalCommand> but I currently ignore
>  it.  My  plan is that this should be saved in the plugin structure and
>  could be used as a default for the config option that Henrik is adding.
>

I reserved a place in the code where you could make use of the ExternalCommand
form the XML EXternal Plugin file ...

See:
http://opensync.org/changeset/5898/trunk/opensync/engine/opensync_engine.c

Best Regards,
Daniel

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Graham Cobb-4]

Just a quick email reply for now -- hopefully I will get some time to actually
work on this later today.  

On Sunday 01 November 2009 13:32:57 Daniel Gollub wrote:
> On Sunday 01 November 2009 01:39:24 am Graham Cobb wrote:
> > I have a first cut of the external plugin config file ready to check in
> > (http://opensync.pastebin.com/m38d98a95).
>
> Thanks, will review your patch ASAP!

Thanks for your feedback, including in your other emails.

> > 1) When I run the unittests, 17 of them fail.  I don't think any of them
> >  are  related to these changes but is that expected at the moment?

> > If it is not expected I will have to do some more checking.
>
> Would be great if you could check whats going wrong there ...
> Those tests also fail if you revert your changes - right?

That is the first step in the "more checking" :-)  I will look into this later
this evening.

> > 2) I have created an example external plugin config file in
> > docs/examples/plugins/src.  Can the existing CMake macros be used to get
> >  that  file installed into the plugin directory (which is where I am
> >  looking for it -- I look for .xml files first, then .so files)?  I
> > haven't tried it but I assume the macros like OPENSYNC_PLUGIN_INSTALL
> > expect a .so file.

> I'll introduce a cmake macro called "OPENSYNC_EXTERNAL_PLUGIN_INSTALL" ...

Thanks, I will use that.

> > 3) The XML format includes <ExternalCommand> but I currently ignore
> >  it.  My  plan is that this should be saved in the plugin structure and
> >  could be used as a default for the config option that Henrik is adding.
>
> Ok, fine with me.

I saw your other email on this.  I will try to get to this today but may not
have time.  I want to concentrate on getting the basic code working and
tested.

> > 4) If the .xml and the .so are both present, they both get loaded and two
> > plugins exist with the same name.  I thought of adding error checking to
> > osync_plugin_set_name to fail if a plugin of the same name is already
> >  loaded.   But I have just noticed that none of the osync_plugin_set_...
> >  calls have OSyncError parameters.  Should they?  This would be an API
> >  change (to a widely used API).

> Anyway, this is a different issue - independent of your planned changes ..
> which should get fixed at some point. I'll create for that a ticket ... in
> my opionoen it's not a blocker, since this could be avoided by distribution
> with sane packaging ;)

OK.  I am not going to worry about this at the moment.

>From your other email:

> Is the drop of osync_module_unload() intended?

Yes, it is necessary.  The pseudo-plugin created by the new external plugin
code has no module->module (it is NULL).  That seems reasonable to me as no
module has been loaded.  The only place that gets upset by this is
osync_module_unload() which asserts that module->module exists.  That also
seems reasonable to me: you shouldn't be trying to unload a module if one was
never loaded.

Fortunately, osync_module_unref() already unloads the module if this is the
last reference and if module->module is non-null (i.e. a module was actually
loaded).  So, it is never necessary to call osync_module_unload()
explicitly -- it will be unloaded automatically when the last reference is
dropped.

In fact, I would even argue it is a bug: the caller does not know that someone
else does not hold a reference and the module should not be unloaded until
the last reference is dropped.

So, yes it is deliberate.  The change to the comment was supposed to give a
hint!

As for ignoring the error on loading the external plugin, you are right that I
did it because that is the way the existing plugin code worked.  You are also
right that we should probably be making the error visible somewhere other
than the trace files and if we *really* want to ignore it we should be
freeing the error struct.  I will add the FIXME.

You mention that you will write an XSD (thanks -- another thing I have never
done!).  Should I validiate the XML file against the XSD before loading it?  
I noticed that some other code (can't remember what, offhand, maybe config
file loading?) does that.

Graham


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Graham Cobb-4]

On Sunday 01 November 2009 13:32:57 Daniel Gollub wrote:
> On Sunday 01 November 2009 01:39:24 am Graham Cobb wrote:
> > 1) When I run the unittests, 17 of them fail.  I don't think any of them
> >  are  related to these changes but is that expected at the moment?
>
> No, actually they should fail.
>
> Could you run: "make Experimental" so the testing resutls get uploaded to
> the CDash dashboard .. so we can have a look on the logs?

I reverted my changes and re-ran the tests.  I got 18 failures.  I ran make
Experimental but I haven't had time to investigate the failures.  I note that
most of them failed with:

/home/Linux/opensync/trunk/tests/mock-plugin/mock_sync.c:241:E:mock_write:
Assertion "!g_file_test(filename, G_FILE_TEST_EXISTS)" failed

Any ideas?

Given that the same errors occur with or without my changes I am going to
check in my changes anyway.

By the way, I normally only run "make test" as I sort of presumed you didn't
want the dashboard full of random tests of developers while they are
debugging their code.  What are the guidelines for when we should run make
Experimental?

I find the CTest verbose logs fairly uninformative in many cases.  Is there
any way to use gdb to step through the test case code (and/or to debug the
OpenSync code)?  

Graham

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Graham Cobb-4]

Daniel,

I have checked in my changes for the external plugin config file (r5906).  
Things still left to do (most important first):

1) Unit tests for the new code

2) ExternalCommand support.

3) Validation against XSD.

As I mentioned, I am travelling on business for the next few weeks.  I
probably won't get much time to look at this (or the timeout stuff) while I
am away.

Graham

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Monday 02 November 2009 12:25:07 am Graham Cobb wrote:
> I have checked in my changes for the external plugin config file (r5906).  

Thanks a lot!

> Things still left to do (most important first):
>
> 1) Unit tests for the new code

Created a ticket for that:
http://opensync.org/ticket/1184

>
> 2) ExternalCommand support.

Implemented:
http://opensync.org/changeset/5914


>
> 3) Validation against XSD.

This is next on my TODO list ...

>
> As I mentioned, I am travelling on business for the next few weeks.  I
> probably won't get much time to look at this (or the timeout stuff) while
>  I  am away.
>

Ok, i'll concentrate on the timeout stuff once the extenral stuff is completed
(very likely after the XSD got written). I need to introduce some more
interface for mapping update ... once this is done we can reenable the IPC
pendingLimit ... see http://opensync.org/ticket/1161

Thanks for your core contribution! ;)
Wish you a safe trip!

Best Regards,
Daniel


--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel