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

[Henrik /K. <he...@ka...>]

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