|
From: Graham C. <g+o...@co...> - 2009-10-27 18:47:19
|
On Tuesday 27 October 2009 17:07:50 Henrik /KaarPoSoft wrote: > Currently both osynctool (or, in a production environment: your own sync > function in your own GUI) and the external process are using the exact > same plugin module (such as mozilla-sync). Henrik, I haven't looked at the code (maybe a good thing so we can discuss how it **should** work). 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? > The external process will then set up an identical environment in > _osync_client_handle_initialize (at least if the external process is > coded in the simplest possible way I could find: calling > osync_client_run_and_block and letting the OpenSync libraries take care > of the rest). 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! > 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? 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. 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). 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. 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. 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. Graham |