Menu
▾
▴
opensync-devel
|
From: Henrik /K. <he...@ka...> - 2009-10-28 21:05:02
Attachments:
external_process.patch
|
Dear all, To my surprise, I have received only ONE comment (thank you Graham!) to my recent postings about OSYNC_START_TYPE_EXTERNAL. Please let me know if anybody objects to me checking in the attached combined patch for all the issues I have raised about OSYNC_START_TYPE_EXTERNAL so far. /Henrik |
|
From: Daniel G. <go...@b1...> - 2009-10-29 14:08:30
|
On Wednesday 28 October 2009 10:04:43 pm Henrik /KaarPoSoft wrote: > Dear all, > > To my surprise, I have received only ONE comment (thank you Graham!) to > my recent postings about OSYNC_START_TYPE_EXTERNAL. Sorry, i wrote several tests this week - looking forward to some more spare time next week. Private things first - you know ;) > > Please let me know if anybody objects to me checking in the attached > combined patch for all the issues I have raised about > OSYNC_START_TYPE_EXTERNAL so far. I like the command_start addition .. this is somethign which was really missing. Could you explain how you use this for mozilla-sync? Do you start mozilla if it isn't already started? Or do you trigger the sync via an additional command? Or both? I'm still not convinced why there is need to overwrite the plugindir ... or maybe i didn't understand the problem. Unfortuantely exactly for the new API function to override the path the API documentation is missing why this is needed ... +OSYNC_EXPORT void osync_client_set_overriding_plugin_dir(OSyncClient *client, char *overriding_plugin_dir); +OSYNC_EXPORT char *osync_client_get_overriding_plugin_dir(OSyncClient *client); + Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... 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 |
|
From: Henrik /K. <he...@ka...> - 2009-10-29 15:48:57
|
Daniel Gollub wrote: > On Wednesday 28 October 2009 10:04:43 pm Henrik /KaarPoSoft wrote: > >> Please let me know if anybody objects to me checking in the attached >> combined patch for all the issues I have raised about >> OSYNC_START_TYPE_EXTERNAL so far. >> > > I like the command_start addition .. this is somethign which was really > missing. Could you explain how you use this for mozilla-sync? > > Do you start mozilla if it isn't already started? Or do you trigger the sync > via an additional command? Or both? > If you call the "thunderbird" program, it will start a new process if it is not already running. I thunderbird is already running, it will simply hand off the command line parameters to the already running instance. The opensync client is triggered by the -mozilla-sync command line option which I added to thunderbird. The sync itself can be triggered by running the engine from osynctool or from inside the blueZync plugin to Thunderbird. > I'm still not convinced why there is need to overwrite the plugindir ... or > maybe i didn't understand the problem. Unfortuantely exactly for the new API > function to override the path the API documentation is missing why this is > needed ... > > +OSYNC_EXPORT void osync_client_set_overriding_plugin_dir(OSyncClient *client, > char *overriding_plugin_dir); > +OSYNC_EXPORT char *osync_client_get_overriding_plugin_dir(OSyncClient > *client); > + > As I wrote in a different thread, I am not sure if my way of implementing the external process is the intended one. I am simply running the same kind of client that would have been running inside osynctool, by calling the same opensync libraries. That means that without osync_client_get_overriding_plugin_dir the opensync library would load the slim mozilla-sync plugin which was intended for osynctool/engine, not the new fat mozilla-sync plugin intended for the external process. /Henrik |
|
From: Graham C. <g+o...@co...> - 2009-10-29 16:24:11
|
On Thursday 29 October 2009 15:48:33 Henrik /KaarPoSoft wrote: > As I wrote in a different thread, I am not sure if my way of > implementing the external process is the intended one. I am simply > running the same kind of client that would have been running inside > osynctool, by calling the same opensync libraries. That means that > without osync_client_get_overriding_plugin_dir the opensync library > would load the slim mozilla-sync plugin which was intended for > osynctool/engine, not the new fat mozilla-sync plugin intended for the > external process. There seem to be two possible solutions: 1) The "thin" plugin could just be replaced with a configuration file. What does OpenSync need to know about external process plugins? Presumably pretty much just the fact that they are external and how to contact them. Should we add a config file to supply that info? Then opensync would just not attempt to load any plugin for which it had already read a config file. 2) Or, the fat plugin could not really be a plugin. It could be completely up to the caller of opensync in the external process to have the plugin code loaded (presumably statically linked into the executable) and opensync, when invoked to just create a client, would not load **any** plugins. There would have to be a function to call to register a plugin by passing in the get_plugin_info address. I **think** this second option was how the original external code worked, but I haven't checked the code so I might be completely wrong. I am keen to keep the external client code as minimal as possible. In particular, if we are every going to make IPC and timeout work properly I certainly don't want two full IPC instances communicating -- there are enough queues as it is! Graham |
|
From: Henrik /K. <he...@ka...> - 2009-10-29 16:47:48
|
Graham Cobb wrote: > On Thursday 29 October 2009 15:48:33 Henrik /KaarPoSoft wrote: > >> As I wrote in a different thread, I am not sure if my way of >> implementing the external process is the intended one. I am simply >> running the same kind of client that would have been running inside >> osynctool, by calling the same opensync libraries. That means that >> without osync_client_get_overriding_plugin_dir the opensync library >> would load the slim mozilla-sync plugin which was intended for >> osynctool/engine, not the new fat mozilla-sync plugin intended for the >> external process. >> > > There seem to be two possible solutions: > > 1) The "thin" plugin could just be replaced with a configuration file. What > does OpenSync need to know about external process plugins? Presumably pretty > much just the fact that they are external and how to contact them. > > Should we add a config file to supply that info? Then opensync would just not > attempt to load any plugin for which it had already read a config file. > Good idea. Daniel, your call! > 2) Or, the fat plugin could not really be a plugin. It could be completely up > to the caller of opensync in the external process to have the plugin code > loaded (presumably statically linked into the executable) and opensync, when > invoked to just create a client, would not load **any** plugins. There would > have to be a function to call to register a plugin by passing in the > get_plugin_info address. > > I **think** this second option was how the original external code worked, but > I haven't checked the code so I might be completely wrong. > Could you point me to where to find "the original external code"? I have not been able to find any implementation of an external process/plugin - except for osplugin. > I am keen to keep the external client code as minimal as possible. In > particular, if we are every going to make IPC and timeout work properly I > certainly don't want two full IPC instances communicating -- there are enough > queues as it is! > I don't think this approach introduces any new queues. I believe there are two bidirectional queues in any case (engine and plugin), it is just a question of whether they are accessed from different threads in the same thread of from different processes. /Henrik |
|
From: Henrik /K. <he...@ka...> - 2009-10-30 17:05:57
Attachments:
external_process_2.patch
|
Hi all, I have earlier provided a patch so a plugin of type OSYNC_START_TYPE_EXTERNAL can set osync_plugin_set_start_external_command. However, after some thought, I actually think it should be on the OSyncPluginConfig. In this way, different members can have different external commands with the same plugin. I.e. the config for mozilla-sync plugin could specify thunderbird or sunbird or even the Debian ice-*. Please find attached a combined patch. Comments? /Henrik |
|
From: Henrik /K. <he...@ka...> - 2009-10-30 17:11:30
|
Just for reference, the external process basically boils down to this
function:
static int run_plugin(BZOpenSyncPlugin *pbz) {
osync_trace(TRACE_ENTRY, "%s", __func__);
OSyncError *error = NULL;
OSyncQueue *incoming = NULL;
OSyncQueue *outgoing = NULL;
OSyncClient *client = NULL;
client = osync_client_new(&error);
if (!client)
goto done;
osync_client_set_overriding_plugin_dir(client, pbz->mySzPathToLib);
/* Create connection pipes **/
incoming = osync_queue_new(pbz->mySzPathToPipe, &error);
if (!incoming)
goto error;
if (!osync_queue_create(incoming, &error))
goto error;
/* We now connect to our incoming queue */
if (!osync_queue_connect(incoming, OSYNC_QUEUE_RECEIVER, &error))
goto error;
if (!osync_client_set_incoming_queue(client, incoming, &error))
goto error;
osync_queue_unref(incoming);
osync_client_run_and_block(client);
osync_client_unref(client);
printf("blueZync synchronization client thread complete\n");
osync_trace(TRACE_EXIT, "%s", __func__);
return NS_OK;
error:
osync_client_unref(client);
done:
osync_trace(TRACE_EXIT_ERROR, "%s: %s", __func__,
osync_error_print(&error));
fprintf(stderr, "Unable to initialize environment: %s\n",
osync_error_print(&error));
osync_error_unref(&error);
return NS_ERROR_FAILURE;
}
Henrik /KaarPoSoft wrote:
> Hi all,
>
> I have earlier provided a patch so a plugin of type
> OSYNC_START_TYPE_EXTERNAL can set
> osync_plugin_set_start_external_command.
>
> However, after some thought, I actually think it should be on the
> OSyncPluginConfig.
>
> In this way, different members can have different external commands
> with the same plugin.
>
> I.e. the config for mozilla-sync plugin could specify thunderbird or
> sunbird or even the Debian ice-*.
>
> Please find attached a combined patch.
>
> Comments?
>
> /Henrik
>
|
Thanks for helping keep SourceForge clean.
X