Re: [Opensync-devel] [RFC] Different libraries for OSYNC_START_TYPE_EXTERNAL

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

Thanks for your comments, Graham.

Here is a bit of "replies" / new comments.

Graham Cobb wrote:
> Do we need to have the plugin running at all in the engine process?  Can the 
> engine just be told (somehow) to create the proxy and talk to the real plugin 
> in the external process?
>   
If I understand correctly, today the engine is loading up all the plugin 
modules, but for an OSYNC_START_TYPE_EXTERNAL plugin, the engine just 
calls a few functions to get info. So we need "something", that the 
engine can call to know how to deal with the external process. I.e. a 
plugin, but a very lightweight one.
> Similarly, we don't really need the engine (let alone the other plugins) 
> running at all in the external process -- just the other end of the proxy 
> connection.  In fact, I thought I remembered that there was a way to do that 
> (but I would have to look at the code!).  I do remember that when I was 
> looking at the timeout stuff I found the client/proxy stuff confusing!
>   
There might be a different way, but I have not found it. But with very 
little documentation it is kind of hard to look through the whole 
codebase and see if there is a bit that fits is quite hard.
But if there is a better way than what I have proposed I am all ears!
One of the reasons for my mails about this is indeed to see if anyone 
has a better way.
>> So I think we need a mechanism which allows a plugin (of type
>> OSYNC_START_TYPE_EXTERNAL) to have TWO different libraries:
>> - one for the engine
>> - one for the external process
>>     
>
> Why does it need one for the engine at all?
>   
See above: We need at least a slim plugin to tell the engine how to 
contact the external process.
> The rough way I had thought this would work...
>
> The external plugin is NOT installed in the usual place for Opensync plugins.
>
> The GUI (or osynctool) creates the engine as normal, which loads all the other 
> plugins.
>
> The GUI (or osynctool) calls a special osync function to tell it that there is 
> a remote plugin accessible over such-and-such a pipe. 
I think this info should come from the slim plugin, not the GUI/osynctool.
>  The engine creates a 
> proxy for this.  At this point the engine believes the plugin exists even 
> though there is only a proxy.  It can be added to groups, etc.
>
> Meanwhile, the external process has created the other end of the proxy NOT by 
> creating the whole engine but just by creating a client (is that the right 
> terminology -- I might have to go and look at the code).
>   
Yes, that is also how it would work in my approach. The external process 
just creates a client (but using the opensync lib, which also includes 
the engine etc, which will not be called).
> Either as part of creating that client, or with a separate function, the 
> external process tells the client where to find the plugin (which is not in a 
> standard place) and connects the plugin to the client, with no engine.
Exactly.
>   It 
> may be that the plugin is not even loaded, in the normal opensync meaning of 
> that term -- it could be a static part of the external process and 
> its "get_sync_info" address is passed to the client.
>   
Sure. My reason for making it a "real" opensync plugin was simply that 
then I could use the opensync client code with minimal modifications.
> The external process then runs the client.
>
> I am sure, from your description, that this is not how it actually works 
> today, but this seems easier than having plugin directory overides.
>
>   
First of all it seems that we agree on the overall principles, which is 
great.

The only question is: How to implement it, and here we have slightly 
different approaches.

However, the difference is not very big!

You suggest the GUI tells the engine about the external process; I 
suggest a "slim" plugin.

You suggest the external process loads the "fat" plugin from a different 
location; you suggest basically the same or that no plugin is loaded at all.


Graham, I really appreciate the feedback you have given!

Comments, anybody ?