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

Re: [Opensync-devel] Patch for evolution plugin

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

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.

> 
> 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?


> 
> <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".

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] missing code in opensync_obj_engine.c

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

On Thursday, June 30, 2011 11:40:41 pm Chris Frey wrote:
[...]
> > Could you please commit this to trunk?
> 
> Hmmm... haven't used SVN in a while... it usually asks me for the
> password, but having trouble with it:
> 
> [cdfrey opensync]$ svn commit
> Password for '(null)' GNOME keyring: 
> svn: Commit failed (details follow):
> svn: MKACTIVITY of '/!svn/act/461be820-9fc7-4dd7-8c7f-75cf411715ff':
> authorization failed: Could not authenticate to server: rejected Basic
> challenge (http://svn.opensync.org)

Strange ...

It just did a dummy commit to test if everything works fine with the 
Subversion server.

I guess you have some trouble with your GNOME keyring - Password for '(null)' 
doesn't soudn right ...

Did you use gnome-keyring integration of subversion in the past?
If no, you might temporarily try to disable it in:
~/.subversion/config


[auth]
stoe-passwords = no
store-auth-creds = no
...

Or try a fresh checkout, so your GNOME keyring stores your creds correctly.


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

[Opensync-devel] Patch for evolution plugin

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

Hi,

With this patch, it works with new Evolution release 2.32 and higher.

Moreover, I have added an option to be able to choose the evolution
addressbook, calendar, tasks or memo  to sync.

My evolution config file :

    <Resource>
      <Enabled>1</Enabled>
      <Formats>
        <Format>
          <Config>VCARD_EXTENSION=Evolution</Config>
          <Name>vcard21</Name>
        </Format>
        <Format>
          <Config>VCARD_EXTENSION=Evolution</Config>
          <Name>vcard30</Name>
        </Format>
      </Formats>
      <Name>Personnel</Name>
      <ObjType>contact</ObjType>
<Url>file:///home/nicolas/.local/share/evolution/addressbook/system</Url>
    </Resource>


<Name>....</Name> : it's to select the good entry in evolution.

(idem for calendar, memo and tasks)


Regards,

Nicolas

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

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

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.

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.


The problem:
------------

Our FindPythonLibs.cmake was hacked to add PYTHON_VERSION.  It basically
called python and asked for its version number.  Simple enough.

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.

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

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

[Chris F. <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

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

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

On Thu, Jun 30, 2011 at 07:28:41AM +0200, Daniel Gollub wrote:
> this fix looks good. I really wonder how this could happen at all ...
> Thank you very much for finding this!
> 
> Could you please commit this to trunk?

Hmmm... haven't used SVN in a while... it usually asks me for the
password, but having trouble with it:

[cdfrey opensync]$ svn commit
Password for '(null)' GNOME keyring: 
svn: Commit failed (details follow):
svn: MKACTIVITY of '/!svn/act/461be820-9fc7-4dd7-8c7f-75cf411715ff': authorization failed: Could not authenticate to server: rejected Basic challenge (http://svn.opensync.org)

- Chris

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

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

Hi Chris,

On Wednesday, June 29, 2011 03:47:30 am Chris Frey wrote:
> I believe this fixes it, but would appreciate your double-check and
> confirmation.

this fix looks good. I really wonder how this could happen at all ...
Thank you very much for finding this!

Could you please commit this to trunk?

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] missing code in opensync_obj_engine.c

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

Hi Daniel,

I believe this fixes it, but would appreciate your double-check and
confirmation.

Thanks,
- Chris


http://repo.or.cz/w/opensync/opensync-cdf.git/blobdiff/184c3b0375a83722c1b0ca144bc41c3bc8998d23..2e54e5125aee9d0a4d8479c1276b7cc49db82677:/opensync/engine/opensync_obj_engine.c



--- a/opensync/engine/opensync_obj_engine.c
+++ b/opensync/engine/opensync_obj_engine.c
@@ -930,8 +930,17 @@ static int _osync_obj_engine_num_write_sinks(OSyncObjEngine *objengine) {
        osync_trace(TRACE_ENTRY, "%s(%p)", __func__, objengine);
 
        for (p = objengine->sink_engines; p; p = p->next) {
+               OSyncMember *member = NULL;
+               OSyncObjTypeSink *objtype_sink = NULL;
+
                sink = p->data;
+               member = osync_client_proxy_get_member(sink->proxy);
+               objtype_sink = osync_member_find_objtype_sink(member, objengine->objtype);
 
+               /* Is the objtype_sink writable? */
+               if (objtype_sink && osync_objtype_sink_get_write(objtype_sink)) {
+                       num++;
+               }
 
        }
 

On Tue, Jun 28, 2011 at 04:39:36PM -0400, Chris Frey wrote:
> Hi Daniel,
> 
> Here's the commit in question:
> 
> http://repo.or.cz/w/opensync/opensync-cdf.git/commit/865414da0d3ffff2a7865fce9c82adcd7587c218
> 
> And the diff:
> 
> http://repo.or.cz/w/opensync/opensync-cdf.git/blobdiff/7f03a5a20921288dd7015777e6b9e648e73624bf..865414da0d3ffff2a7865fce9c82adcd7587c218:/opensync/engine/opensync_obj_engine.c
> 
> The function _osync_obj_engine_num_write_sinks() appears to be incomplete.
> 
> Could you give me an overview of what you intended?
> 
> Thanks!
> - Chris
> 
> 
> ------------------------------------------------------------------------------
> 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

[Opensync-devel] missing code in opensync_obj_engine.c

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

Hi Daniel,

Here's the commit in question:

http://repo.or.cz/w/opensync/opensync-cdf.git/commit/865414da0d3ffff2a7865fce9c82adcd7587c218

And the diff:

http://repo.or.cz/w/opensync/opensync-cdf.git/blobdiff/7f03a5a20921288dd7015777e6b9e648e73624bf..865414da0d3ffff2a7865fce9c82adcd7587c218:/opensync/engine/opensync_obj_engine.c

The function _osync_obj_engine_num_write_sinks() appears to be incomplete.

Could you give me an overview of what you intended?

Thanks!
- Chris

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

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

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

Re: [Opensync-devel] How to break the library api nicely

[Juha T. <Juh...@ik...>]

On Wednesday 08 June 2011 08:38:13 Luiz Angelo Daros de Luca wrote:
> As I suggested, I will provide some patches in order to rename plugin
> callback functions. This will break
> plugin implementation. I was thinking about how to do it nicely. My
> suggestion is:
> 
> 1) Keep old function names and mark it as deprecated
> 2) Implement the new names
> 3) Look for plugins use and fix them
> 
> I'm just not sure which plugins should I propose a fix. Also, there is the
> upgrade doc to be written.

This kind of changes support the viewpoint, that all plugins should be hosted 
in opensync.org - it would make it a whole lot easier to users so that their 
needed plugs stay compatible with the main releases.

Tuju

-- 
Better to have one, and not need it, than to need one and not have it.

[Opensync-devel] How to break the library api nicely

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

Hello,

As I suggested, I will provide some patches in order to rename plugin
callback functions. This will break
plugin implementation. I was thinking about how to do it nicely. My
suggestion is:

1) Keep old function names and mark it as deprecated
2) Implement the new names
3) Look for plugins use and fix them

I'm just not sure which plugins should I propose a fix. Also, there is the
upgrade doc to be written.

Regards,

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

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

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

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


2011/6/6 Chris Frey <cd...@fo...>

> On Wed, Jun 01, 2011 at 02:09:25AM -0300, Luiz Angelo Daros de Luca wrote:
> > Maybe we are talking about different things. :-) The objformat is already
> > avaiable to who askes for it.
> > My suggestion is to do something like these:
> >
> > char *osync_objformat_print(OSyncObjFormat *format, const char *data,
> > unsigned int size, OSyncError **error) {
> >     (...)
> > +   return format->print_func(data, size, format->user_data, error);
> > -    return format->print_func(format, data, size, format->user_data,
> > error);
> > }
> >
> > And so on for all callbacks. plugin and sink does just like this. My ruby
> > wrapper can implement multiple objformats (and plugins) and I have, for
> each
> > callback type, only one C callback for all ruby objects. If I have
> > the format inside the callback, I can look for the ruby callback defined
> for
> > this format.
>
> Sorry for the delay.  I'm sure this is frustrating for you.  I hope you
> don't give up! :-)
>
>
Not yet :-) I was fighting with video encoders the last days... Opensync
looks like a sunny
day when looking at some  "... leading audio/video codec library"


> I have to be honest, that adding this argument, as a special case for
> wrapper code, just feels like the wrong move. :-)
>

It could be used for any format that wishes to share a callback
function. For example:

print_func(format, data, user_data) {
     print "Data from %s", get_name(format))
     print data
     if (get_name(format)=="file") {
         print user_data.filename;
     }
}


>
>  From a C perspective, this kind of data belongs in the user_data block.
> By including the format pointer in the user_data (which you need in order
> to register print_func), you have everything you need.
>

print_func was just an example. My real problem is that initialize, which
defines user_data,
is already a callback function and it has no arguments. I have unique C
callback, one for each type. Every format
"instance" shares the same callback in C world. This callback, with the help
of some data (user_data), retrieve the
ruby callback for this format "instance" and call it. However, initialize
does not have arguments but error. So
there is nowhere to retrieve the "data". It is a chiken'n'egg problem.

When initialize is called, I don't know which format is initialing. Remember
that this function is shared among all
ruby format objects that defined the initialize function. However, if it
was:

static void *osync_rubymodule_objformat_initialize(OSyncObjFormat
*format, OSyncError **error)

I could, based on format, retrieve the ruby callback, initialize user_data
and return it. Without format, I have no solution.

I can solve my problem only adding format to initialize arguments. However,
I suggest that all of callbacks should pass the struct that it is related.


> - Chris
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

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

On Wed, Jun 01, 2011 at 02:14:16AM -0300, Luiz Angelo Daros de Luca wrote:
> I still didn't understand what would be "binary-meta". Maybe it is because
> I'm not a native english speaker (BTW, I'm from Brazil).
> 
> Is it about distribution packaging (deb,rpm)? Like split libraries and
> programs in different packages?

Yes.  It is "binary" in that it is focused on creating binary packages.
So far, only Debian-style.

It is "meta" in that it uses git submodules to pull in external source
repos.  Each of those other git repos are standalone, and can be used
by themselves, but the "binary-meta" repo pulls them all together to
make it easy to build everything in one go.

- Chris

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

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

On Wed, Jun 01, 2011 at 02:09:25AM -0300, Luiz Angelo Daros de Luca wrote:
> Maybe we are talking about different things. :-) The objformat is already
> avaiable to who askes for it.
> My suggestion is to do something like these:
> 
> char *osync_objformat_print(OSyncObjFormat *format, const char *data,
> unsigned int size, OSyncError **error) {
>     (...)
> +   return format->print_func(data, size, format->user_data, error);
> -    return format->print_func(format, data, size, format->user_data,
> error);
> }
> 
> And so on for all callbacks. plugin and sink does just like this. My ruby
> wrapper can implement multiple objformats (and plugins) and I have, for each
> callback type, only one C callback for all ruby objects. If I have
> the format inside the callback, I can look for the ruby callback defined for
> this format.

Sorry for the delay.  I'm sure this is frustrating for you.  I hope you
don't give up! :-)

I have to be honest, that adding this argument, as a special case for
wrapper code, just feels like the wrong move. :-)

 From a C perspective, this kind of data belongs in the user_data block.
By including the format pointer in the user_data (which you need in order
to register print_func), you have everything you need.

- Chris

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

[Emanoil K. <del...@ya...>]

--- On Thu, 6/2/11, Chris Frey <cd...@fo...> wrote:

> 
> Thanks for the questions... it forced me to probe a little
> deeper into
> the code. :-)
> 
> - Chris
> 

And thanks Chris for finding the time to do this and write it down

regards

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

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

On Wed, Jun 01, 2011 at 01:53:38AM -0300, Luiz Angelo Daros de Luca wrote:
> Hello,
> 
> I was and I'll be "offline" until weekend but lets answer and ask
> somethings...

No problem :-)


> 2011/5/27 Chris Frey <cd...@fo...>
> 
> > On Fri, May 27, 2011 at 01:24:28AM -0300, Luiz Angelo Daros de Luca wrote:
> > > So, I have some suggestions:
> > >
> > > * make all _new function behave the same: only malloc or malloc and
> > > also define mandatory attributes.
> > > * if _new only mallocs, create the necessary setters and getters for
> > > each of the attributes
> >
> > I'm not entirely sure that objformat's name is supposed to change.
> > These names show up in the osynctool --listformats output.
> >
> > I favour APIs that make it impossible to do the wrong thing, and
> > I suspect that this _new(), with attributes, is doing that.
> >
> 
> Sure, my suggestion is just to unify some behavior. Why plugin has a
> set_name and format doesn't?
> Remove from plugin or add it to format. That is my idea.

I'm guessing because plugin had the longname and description to worry about,
and putting that in one function was probably unwieldy.


> I'm just afraid that mandatory parameters result in something like these:
> 
> plugin/opensync_objtype_sink.c
> OSyncObjTypeSink *osync_objtype_main_sink_new(OSyncError **error)
> {
>     return osync_objtype_sink_new(NULL, error);
> }
> 
> OSyncObjTypeSink *osync_objtype_sink_new(const char *objtype, OSyncError
> **error)
> 
>           {
>           ...

The main sink is a special case of regular sinks.  It appears to be
stored as a special pointer in the OSyncPluginInfo struct.  I think it is just
an implementation detail that it reuses the regular sink code.

I wish there was more documentation on what main sinks do.  I'm not
sure I understand your objection to the above code.  To me, it is
clearer to have a function name associated with a null objtype name.
Otherwise, we wouldn't know that this was a special case.


> IMHO, I prefer smaller methods that do a single step and which the arguments
> order follows some kind of general pattern.
> For example. when I compare:
> 
>         plugin = osync_plugin_new(error)
> osync_plugin_set_name(plugin, "file-sync");
>  osync_plugin_set_longname(plugin, "File Synchronization Plugin");
> osync_plugin_set_description(plugin, "Plugin to synchronize files on the
> local filesystem");
>         osync_plugin_env_register_plugin(env, plugin, error)
> 
>   and:
> 
>         plugin = osync_plugin_new("file-sync", "File Synchronization
> Plugin", "Plugin to synchronize files on the local filesystem",error);
>         osync_plugin_env_register_plugin(env, plugin, error)
> 
> Although the first uses many more code, it explains by itself while the
> second case, I would need to know the parameters order to infer what is
> what. The real problem is that what would be accessible by a setter/getter
> method in plugin is not valid for objformat. I like the rule that the
> "programmer" know what to do.

I like code that describes itself too, but that's not the only consideration.
I think there is something more going on here (see comments on
set/get_data below).


> It is a lost battle to try to save the programmer from its own mistakes. :-)

I strongly disagree with this, as programmers need all the help they
can get. :-)  And saving myself from my own mistakes has helped me more
than I can remember, especially as code gets larger, and my brain gets
older.


> > > * add a set/get_data to objformat.
> >
> > I can see adding a get_userdata(), but the set_userdata() is handled
> > by the initialize callback.  By adding set_userdata(), we'd introduce
> > a potential race condition during setup, depending which was called
> > first.
> >
> 
> This case happens in plugin. Is "race condition" about threadsafeness? Is
> opensync design thread-safe? If is just about a double set_userdata, in my
> case, I just return the same user_data that I previously saved. Another
> question: should plugin intialize be only about allocationg userdata or it
> should also set sinks (like in file-sync).
> 
> I'm getting into a point that I think userdata is not enough for my userdata
> needs. I think that I'll need to use my "hacked userdata" for plugin, sink
> and objtype. I need to have a struct to store callbacks and I cannot wait
> until a initialize callback is called in order to allocate this struct.

In reading through the code, it would appear that even the plugin's
set/get_data functions do not do what I thought they did.

It looks like it is consistent: an initialize callback returns its own
user data.  This works for plugins and formats.  The data returned by
the initialize function is passed into the other callbacks, including
the finalize callback.  The data in osync_plugin_set_data() is not.

The plugin data set by osync_plugin_set_data() is never passed back to
any callbacks.  (I did a compile test to make sure... let me know if
you find out differently.)

The data set by osync_objtype_sink_set_userdata() is passed back to the
callbacks set by osync_objtype_sink_set_connect_func() and friends.
These callbacks do not have initialize/finalize associated with them,
since they are setting the sink config for the plugin, not the objformat.
See the linking of plugins and objformats in OSyncPluginInfo.

And similar to the plugin, the objformat user_data defined in
struct OSyncObjFormat is set by the objformat's initialize callback,
and is passed into _its_ callbacks, including finalize.  So far, there
is no get or set for this user_data, and there is no code that needs
access to this user_data except the callbacks themselves, and they have
it in the arguments.

So OpenSync _is_ consistent... just not our understanding of it. :-)



> > > * Some callbacks returns values while others not. Why return
> > > osync_bool if error is enough to tell if the function
> > > worked? Why force initialization to return a void* if, maybe, the
> > > initialization is not used to create a struct for data?
> >
> > If you could point out concrete examples, we could make sure.
> > I'm all for simplifying the API, but maybe the library checks the
> > return values on some of these.  We'd have to reverse engineer the
> > reasoning from the code. :-)
> >
> 
> About the initialize void*, it is a suggestion to let set_data do the job
> and about the bool return,
> it is just redundancy to return OK/FAIL and also error. Should error be
> enough to tell that it failed?

Our understanding of the void* return was faulty... it is not obvious to
me that the void* return is unique... there is no set_data() equivalent.


Thanks for the questions... it forced me to probe a little deeper into
the code. :-)

- Chris

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

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

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


2011/5/27 Chris Frey <cd...@fo...>

> On Fri, May 27, 2011 at 02:03:23AM -0300, Luiz Angelo Daros de Luca wrote:
> > Hello Chris,
> >
> > Oh, you are using git now? I got the svn but I think it is outdate.
> > Should I use your git?
>
> I'm just beginning to move opensync into git, and I'm working on a
> git repo called "binary-meta" that creates binary packages for the
> library and plugins in-place, without having to install opensync itself
> as a dependency.
>
>        http://repo.or.cz/w/opensync/binary-meta.git
>
> It is still a work in progress.  I think I'm the only one working on
> opensync itself right now, but I would like it if developers followed my
> git repo instead of SVN.  I'd like it if developers would create
> their own git repos as well, and then we can pass around patches and
> changes that way.
>

I still didn't understand what would be "binary-meta". Maybe it is because
I'm not a
native english speaker (BTW, I'm from Brazil).

Is it about distribution packaging (deb,rpm)? Like split libraries and
programs in different packages?



>
> Including your ruby work, if git is your thing. :-)  I don't know what
> source control you are most comfortable with.
>
>
> > I'm still improving the plugin but I faced the format callback problem
> > and I have no solution for it (without changing opensync API).
> >
> > I'll try to hack a solution for it...
>
> I have no answer for you yet, but hopefully soon.
>
> - Chris
>
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

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

Now my real problem :-)

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


2011/5/27 Chris Frey <cd...@fo...>

> On Fri, May 27, 2011 at 01:24:28AM -0300, Luiz Angelo Daros de Luca wrote:
> > Hello Chris,
> >
> > I hope that, if you see my code, it didn't scary you. :-)
> > I have finished the plugin implementation part and I also almost
> > finished the ruby-file-sync example. However, I cannot finish the
> > plugin without a format implementation.
> >
> > Here comes my problem: formats have no data. There is no
> > osync_objformat_set_data. I implemented it using the
> > same strategy that I used to workarround the missing
> > osync_objtype_sink_get_userdata. It was all ok until I started to
> > implement the first objformat callback router method. All format
> > callbacks do not have an OSyncObjFormat argument, as
> > plugin and objettype sink callbacks have OSyncPlugin and
> > OSyncObjTypeSink. The only way to define data is by returning some
> > pointer from initialization function.
>
> Yeah, I see how that could be a problem for a wrapper.
>
> I'm guessing a bit here, but I believe that implementing the objformat
> userdata that way means that the objformat names can be known, while
> not using much memory.  If any objformat is needed during the sync,
> then it could be initialized on the fly.
>
> If all objformats had to be initialized at the beginning, and only
> two were needed, it would be a waste.
>

Maybe we are talking about different things. :-) The objformat is already
avaiable to who askes for it.
My suggestion is to do something like these:

char *osync_objformat_print(OSyncObjFormat *format, const char *data,
unsigned int size, OSyncError **error) {
    (...)
+   return format->print_func(data, size, format->user_data, error);
-    return format->print_func(format, data, size, format->user_data,
error);
}

And so on for all callbacks. plugin and sink does just like this. My ruby
wrapper can implement multiple objformats (and plugins) and I have, for each
callback type, only one C callback for all ruby objects. If I have
the format inside the callback, I can look for the ruby callback defined for
this format.


> Is it possible to make use of this in ruby?  i.e. only initialize
> things when asked for?  The only key you can use would be the objformat
> name, but that does not change once created.
>

Sure, I can initialize a plugin, register it and so on. I even call ref when
I receive some argument and call unref when GC cleans it.
It is not a problem for me.



>
> - Chris
>
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

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

Hello,

I was and I'll be "offline" until weekend but lets answer and ask
somethings...

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


2011/5/27 Chris Frey <cd...@fo...>

> On Fri, May 27, 2011 at 01:24:28AM -0300, Luiz Angelo Daros de Luca wrote:
> > So, I have some suggestions:
> >
> > * make all _new function behave the same: only malloc or malloc and
> > also define mandatory attributes.
> > * if _new only mallocs, create the necessary setters and getters for
> > each of the attributes
>
> I'm not entirely sure that objformat's name is supposed to change.
> These names show up in the osynctool --listformats output.
>
> I favour APIs that make it impossible to do the wrong thing, and
> I suspect that this _new(), with attributes, is doing that.
>

Sure, my suggestion is just to unify some behavior. Why plugin has a
set_name and format doesn't?
Remove from plugin or add it to format. That is my idea.

I'm just afraid that mandatory parameters result in something like these:

plugin/opensync_objtype_sink.c
OSyncObjTypeSink *osync_objtype_main_sink_new(OSyncError **error)
{
    return osync_objtype_sink_new(NULL, error);
}

OSyncObjTypeSink *osync_objtype_sink_new(const char *objtype, OSyncError
**error)

          {
          ...

IMHO, I prefer smaller methods that do a single step and which the arguments
order follows some kind of general pattern.
For example. when I compare:

        plugin = osync_plugin_new(error)
osync_plugin_set_name(plugin, "file-sync");
 osync_plugin_set_longname(plugin, "File Synchronization Plugin");
osync_plugin_set_description(plugin, "Plugin to synchronize files on the
local filesystem");
        osync_plugin_env_register_plugin(env, plugin, error)

  and:

        plugin = osync_plugin_new("file-sync", "File Synchronization
Plugin", "Plugin to synchronize files on the local filesystem",error);
        osync_plugin_env_register_plugin(env, plugin, error)

Although the first uses many more code, it explains by itself while the
second case, I would need to know the parameters order to infer what is
what. The real problem is that what would be accessible by a setter/getter
method in plugin is not valid for objformat. I like the rule that the
"programmer" know what to do. It is a lost battle to try to save the
programmer from its own mistakes. :-)


>
> > * add a set/get_data to objformat.
>
> I can see adding a get_userdata(), but the set_userdata() is handled
> by the initialize callback.  By adding set_userdata(), we'd introduce
> a potential race condition during setup, depending which was called
> first.
>

This case happens in plugin. Is "race condition" about threadsafeness? Is
opensync design thread-safe? If is just about a double set_userdata, in my
case, I just return the same user_data that I previously saved. Another
question: should plugin intialize be only about allocationg userdata or it
should also set sinks (like in file-sync).

I'm getting into a point that I think userdata is not enough for my userdata
needs. I think that I'll need to use my "hacked userdata" for plugin, sink
and objtype. I need to have a struct to store callbacks and I cannot wait
until a initialize callback is called in order to allocate this struct.


>
>
> > * Some callbacks returns values while others not. Why return
> > osync_bool if error is enough to tell if the function
> > worked? Why force initialization to return a void* if, maybe, the
> > initialization is not used to create a struct for data?
>
> If you could point out concrete examples, we could make sure.
> I'm all for simplifying the API, but maybe the library checks the
> return values on some of these.  We'd have to reverse engineer the
> reasoning from the code. :-)
>

About the initialize void*, it is a suggestion to let set_data do the job
and about the bool return,
it is just redundancy to return OK/FAIL and also error. Should error be
enough to tell that it failed?


>
>
> > * Choose one unique data field name. I found three: user_data, userdata
> and data
>
> I'd go with userdata, since that's self-documenting.  Patches welcome.
>
>
I'll try to do some coding on weekend.


>
> > * Plugin callback define methods in plugin
> > (set_initialize/finalize/discovery) does not have a suffix like in
> > sink and others. Maybe a osync_plugin_set_initialize_func would sound
> > better.
>
> Sounds good to me.  Patches welcome.
>

I'll try to do some coding on weekend.


>
> >  * Is there any difference in osync_format and osync_objformat? I know
> > that there is only osync_format_env but this format isn't really
> > objformat?
>
> I think the goal was to somehow link the naming of objformat with
> objtype, instead of just the plain "format" and "type".  There are
> a few top level objtypes, but there can be many objformats for each
> objtype.
>
> osync_format_ functions appear to be the namespace used for conversions.
>
> As I understanding, there are objtypes, each objtype can have multiple
> objformats, and then to make use of them, you can create format_env
> environments with which to convert between objformats.
>
> I think the naming is ok here... maybe not consistent from a function
> naming perspective, but from a meaning perspective, it helps to
> remember the hierarchy of types.
>
> Let me know if you disagree. :-)
>

I looked the code and it seems that this is related to dynamic loading of
format modules (which contains objformats and converters) and keeping the
registry of it. Maybe the format-module name that is not sounding OK. It is
not objformat and not converter. It deals with both.


>
> Thanks!
>

Thanks also!


> - Chris
>
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>

Re: [Opensync-devel] official git

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

On Sat, May 28, 2011 at 12:04:10PM +0300, Juha Tuomala wrote:
> Git has been discussed time to time and personally I'm pro for it, it appears 
> to be very popular and could bring it's small share to speed up the 
> development.
> 
> We have planned server changes but they are still waiting to happen, maybe 
> this summer. It would be logical change at the same time.

That sounds great.  I'd be happy to push my repos to the official server
when it's available.

- Chris

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

[Juha T. <Juh...@ik...>]

On Friday 27 May 2011 08:32:03 Chris Frey wrote:
> I'm just beginning to move opensync into git, and I'm working on a
> git repo called "binary-meta" that creates binary packages for the
> library and plugins in-place, without having to install opensync itself
> as a dependency.
> 
> 	http://repo.or.cz/w/opensync/binary-meta.git
> 
> It is still a work in progress.  I think I'm the only one working on
> opensync itself right now, but I would like it if developers followed my
> git repo instead of SVN.  I'd like it if developers would create
> their own git repos as well, and then we can pass around patches and
> changes that way.

Git has been discussed time to time and personally I'm pro for it, it appears 
to be very popular and could bring it's small share to speed up the 
development.

We have planned server changes but they are still waiting to happen, maybe 
this summer. It would be logical change at the same time.


Tuju

-- 
Better to have one, and not need it, than to need one and not have it.

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

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

On Fri, May 27, 2011 at 01:24:28AM -0300, Luiz Angelo Daros de Luca wrote:
> Hello Chris,
> 
> I hope that, if you see my code, it didn't scary you. :-)
> I have finished the plugin implementation part and I also almost
> finished the ruby-file-sync example. However, I cannot finish the
> plugin without a format implementation.
> 
> Here comes my problem: formats have no data. There is no
> osync_objformat_set_data. I implemented it using the
> same strategy that I used to workarround the missing
> osync_objtype_sink_get_userdata. It was all ok until I started to
> implement the first objformat callback router method. All format
> callbacks do not have an OSyncObjFormat argument, as
> plugin and objettype sink callbacks have OSyncPlugin and
> OSyncObjTypeSink. The only way to define data is by returning some
> pointer from initialization function.

Yeah, I see how that could be a problem for a wrapper.

I'm guessing a bit here, but I believe that implementing the objformat
userdata that way means that the objformat names can be known, while
not using much memory.  If any objformat is needed during the sync,
then it could be initialized on the fly.

If all objformats had to be initialized at the beginning, and only
two were needed, it would be a waste.

Is it possible to make use of this in ruby?  i.e. only initialize
things when asked for?  The only key you can use would be the objformat
name, but that does not change once created.

- Chris

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

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

On Fri, May 27, 2011 at 01:24:28AM -0300, Luiz Angelo Daros de Luca wrote:
> So, I have some suggestions:
> 
> * make all _new function behave the same: only malloc or malloc and
> also define mandatory attributes.
> * if _new only mallocs, create the necessary setters and getters for
> each of the attributes

I'm not entirely sure that objformat's name is supposed to change.
These names show up in the osynctool --listformats output.

I favour APIs that make it impossible to do the wrong thing, and
I suspect that this _new(), with attributes, is doing that.


> * add a set/get_data to objformat.

I can see adding a get_userdata(), but the set_userdata() is handled
by the initialize callback.  By adding set_userdata(), we'd introduce
a potential race condition during setup, depending which was called
first.


> * Some callbacks returns values while others not. Why return
> osync_bool if error is enough to tell if the function
> worked? Why force initialization to return a void* if, maybe, the
> initialization is not used to create a struct for data?

If you could point out concrete examples, we could make sure.
I'm all for simplifying the API, but maybe the library checks the
return values on some of these.  We'd have to reverse engineer the
reasoning from the code. :-)


> * Choose one unique data field name. I found three: user_data, userdata and data

I'd go with userdata, since that's self-documenting.  Patches welcome.


> * Plugin callback define methods in plugin
> (set_initialize/finalize/discovery) does not have a suffix like in
> sink and others. Maybe a osync_plugin_set_initialize_func would sound
> better.

Sounds good to me.  Patches welcome.


>  * Is there any difference in osync_format and osync_objformat? I know
> that there is only osync_format_env but this format isn't really
> objformat?

I think the goal was to somehow link the naming of objformat with
objtype, instead of just the plain "format" and "type".  There are
a few top level objtypes, but there can be many objformats for each
objtype.

osync_format_ functions appear to be the namespace used for conversions.

As I understanding, there are objtypes, each objtype can have multiple
objformats, and then to make use of them, you can create format_env
environments with which to convert between objformats.

I think the naming is ok here... maybe not consistent from a function
naming perspective, but from a meaning perspective, it helps to
remember the hierarchy of types.

Let me know if you disagree. :-)

Thanks!
- Chris

Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

[Emanoil K. <del...@ya...>]

sorry for mixing up but I try to follow

For me it was also not easy to find out how it's working.
Format is stored with osync_data_new

OSyncData *odata = osync_data_new ( newData, newDataSize, format, &oerror );

so once you have the data you have the format, but perhaps some improvements would be nice.

However I don't understand why doesn't someone fix the syncml stuff as it seems to be crucial for the whole opensync project and then do whatever else.

Sorry also for putting it here this way, but it's realy annoying after all those years to not have a working solution.

If someone has a working step by step howto for syncing mobiles with linux it would be nice to share with us. 

Without this functionality the whole opensync story looks like an infant criple to me.

regards
--- On Fri, 5/27/11, Luiz Angelo Daros de Luca <lui...@gm...> wrote:

> From: Luiz Angelo Daros de Luca <lui...@gm...>
> Subject: Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?
> To: "Chris Frey" <cd...@fo...>
> Cc: ope...@li...
> Date: Friday, May 27, 2011, 6:24 AM
> Hello Chris,
> 
> I hope that, if you see my code, it didn't scary you. :-)
> I have finished the plugin implementation part and I also
> almost
> finished the ruby-file-sync example. However, I cannot
> finish the
> plugin without a format implementation.
> 
> Here comes my problem: formats have no data. There is no
> osync_objformat_set_data. I implemented it using the
> same strategy that I used to workarround the missing
> osync_objtype_sink_get_userdata. It was all ok until I
> started to
> implement the first objformat callback router method. All
> format
> callbacks do not have an OSyncObjFormat argument, as
> plugin and objettype sink callbacks have OSyncPlugin and
> OSyncObjTypeSink. The only way to define data is by
> returning some
> pointer from initialization function.
> 
> ObjFormat seems to follow some logic different from what
> Sink and
> Plugin uses. Take  osync_objformat_new for example. It
> sets the
> objformat name and objtype name and there is no
> osync_objformat_set_name. I guess that unifying some
> behavior would
> help the API users.
> 
> So, I have some suggestions:
> 
> * make all _new function behave the same: only malloc or
> malloc and
> also define mandatory attributes.
> * if _new only mallocs, create the necessary setters and
> getters for
> each of the attributes
> * add a set/get_data to objformat.
> * Some callbacks returns values while others not. Why
> return
> osync_bool if error is enough to tell if the function
> worked? Why force initialization to return a void* if,
> maybe, the
> initialization is not used to create a struct for data?
> * Choose one unique data field name. I found three:
> user_data, userdata and data
> * Plugin callback define methods in plugin
> (set_initialize/finalize/discovery) does not have a suffix
> like in
> sink and others. Maybe a osync_plugin_set_initialize_func
> would sound
> better.
>  * Is there any difference in osync_format and
> osync_objformat? I know
> that there is only osync_format_env but this format isn't
> really
> objformat?
> 
> If some of these are accepted, I can provide some patches.
> 
> ---
>      Luiz Angelo Daros de Luca, Me.
>             lui...@gm...
> 
> 
> 2011/5/25 Luiz Angelo Daros de Luca <lui...@gm...>
> >
> > Hello Chris,
> > I'm sending my ruby plugin. It still misses some
> important stuff but it is getting there.
> > Maybe this can help me to show you exactly what I am
> doing.
> > I am using osyncplugin in order to test it. When I
> finish the filesync implementation, I will test it with some
> data.
> > RUBYLIB=...libopensync-plugin-ruby-0.39/src
> /usr/bin/osyncplugin --configdir ~/.opensync/ --config
> ~/.opensync/group1/2/file-sync.conf --pluginpath
> ~/prog/opensync/libopensync-plugin-ruby-0.39/build/src/
> --plugin ruby-file-sync --initialize
> > I still need to implement the "loader part", which
> looks for ruby files somewhere, some OSyncData stuff and, I
> hope, file format plugin support.
> > I copied the SWIG generated file into src but cmake
> can generate it in build and compile the module.
> > There is a example file in src/example tha might show
> what a plugin developer will need to write in order to have
> a working plugin. I also wrote some instructions at the
> top of this file.
> > Now your questions...
> >
> > 2011/5/23 Chris Frey <cd...@fo...>
> >>
> >> On Mon, May 23, 2011 at 11:26:55AM -0300, Luiz
> Angelo Daros de Luca wrote:
> >> > Class Info
> >> >    def objtype_sinks
> >> >        
> Opensync::osync_objtype_sink_get_objtype_sinks(@_self).collect
> >> > {|_sink| Sink.for(_sink) }
> >> >    end
> >> > end
> >> >
> >> > It is a little different approach from what I
> saw in python-module plugin.
> >> > All logic is inside ruby world and C code is
> just for wrapping.
> >>
> >> Thanks for the explanation and code.  Please keep
> in mind that I didn't
> >> make the original change in opensync to make the
> _get_ function that you
> >> need internal, so I want to make sure I understand
> all the reasons before
> >> I change it.  It's easy to change, but maybe
> there's a reason behind
> >> it that is useful.  I'm trying to maintain
> opensync, but I didn't write
> >> most of it. :-)
> >
> > I know. We try to do the best we can. The code I'm
> sending might help on this topic.
> >
> >>
> >> As you say, less code, less bugs... that goes for
> the library side too. :-)
> >>
> >> The userdata is basically application data, and it
> is assumed that the
> >> application will keep track of it, and free it,
> etc.
> >
> > For every other information (slow_sync, info...), it
> is opensync choice to show it or not. However, specially
> userdata,
> > it is too much developer choice how to use it. As a
> newbie in opensync, I might be wrong but I think that
> opensync may not gain controlling it. It just complicate the
> developer's world.
> >
> >>
> >> So, I hope this is my last question. :-)  If you
> just get a list
> >> of objtype_sinks with the code above, then when
> you need to register
> >> a callback, how do you know which sink to use?
> >>
> >
> > The code will show but I'll try to explain. In Ruby, I
> have access to all parameters that the callbacks receive,
> including PluginInfo. In plugin initialization callback
> (already inside ruby), I ask for sinks and set my callback
> functions for each of them. My set_xxx_func receives the
> sink pointer and the ruby callback. It just save this
> information inside the sink userdata. Also, it defines a C
> world callback for it. As a C callback receives sink and
> even userdata, it is easy to get ruby callback reference and
> invoke it. The hard part is just the set_xxx_func that has
> no access to userdata.
> >
> >>
> >> I don't see where you're connecting the sink and
> the callback in your
> >> code.  And if you have a list of sinks already,
> maybe it would be wise
> >> to store your userdata along with it?
> >>
> >> i.e. If you have a Sink object that contains your
> sink pointer, and
> >> the ruby programmer asks to register a callback
> via some Sink object
> >> method, why wouldn't the userdata be stored in
> Sink itself?
> >
> > I changed some of this code. userdata now contains
> only the callback functions and a single ruby data. There is
> no reference to sink itself.
> >
> >>
> >> I'm leaning toward exposing
> osync_objtype_sink_get_userdata() anyway,
> >> I just want to fully understand the change.
> >>
> >>
> >> > Sorry, I guess I wasn't clear. I just asked
> why the name of
> >> > osync_objtype_sink_set_userdata is this and
> not osync_objtype_sink_set_data
> >> > like in osync_plugin_set_data. I was worried
> that
> >> > osync_objtype_sink_set_userdata might
> >> > be designed to store something other than a
> pointer for plugin developer own
> >> > use. If it is just like what
> osync_plugin_set_data is for plugins but for
> >> > sinks, I'm fine.
> >>
> >> Yep, both are just void* pointers that opensync
> stores for the app's use.
> >>
> >> Maybe a rename is in order before 0.40. :-)
> >>
> > It is good to know :-)
> > BTW, while writing a ruby version of file-sync-plugin,
> I found some strange things that might be bugs:
> > 1) It unref OsyncError on methods that does not own
> error pointer (i.e. get_sync_info). I read somewhere that
> this is not what it is supposed to happen.
> > 2) plugin data (a.k.a. OSyncFileEnv) has a field
> named directories that should store sink userdata. However,
> it is never defined (always null) and sink's userdata might
> never go. Memory leak?
> > 3) all methods that use the filename passes it to
> filename_scape_characters except osync_filesync_read that
> uses it directly. Is it expected?
> > Thanks,
> > ---
> >      Luiz Angelo Daros de Luca, Me.
> >             lui...@gm...
> 
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing
> security.
> With the market-leading solution for virtual backup and
> recovery, 
> you get blazing-fast, flexible, and affordable data
> protection.
> Download your free trial now. 
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>