Re: [Opensync-devel] [RFC][PATCH] OSYNC_START_TYPE_EXTERNAL

[Graham C. <g+o...@co...>]

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