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

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

Dear all,

I am working on porting mozilla-sync to use OSYNC_START_TYPE_EXTERNAL.

I already send a mail about this on the list ("[RFC] Using 
OSYNC_START_TYPE_EXTERNAL") on which I still hope to get comments.

However, one more conceptual question has come up, and I would like to 
discuss this with the community.

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).

In fact, the engine (e.g. in osynctool) will initialize a proxy, and 
this proxy will send the name of the plugin and the path to the plugin 
directory to 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).

This means that the engine (e.g. in osynctool) will load all plugin 
modules, which in turn leads to loading all the libraries the module 
depends on.

In the mozilla-sync case that means xpcom libraries etc.

It also means that the mozilla-sync plugin will need to be compiled the 
Mozilla development files.

All of this totally unnecesary, as all the Mozilla-relevant stuff is 
taking place in the external process.

The external process will also load all plugin modules - again totally 
unnecessary since it will only need a single plugin.

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

A very simple way to accomplish this would be:

1)
Add a field to struct OSyncClient:
char *overriding_plugin_dir

2)
Add corresponding getters and setters in osync_client.c

3)
In _osync_client_handle_initialize (which gets passed the OSyncClient)
If overriding_plugin_dir<>NULL then call
osync_plugin_env_load(client->plugin_env, overriding_plugin_dir, error)
instead of
osync_plugin_env_load(client->plugin_env, plugindir, error)

4)
Now the external process can set overriding_plugin_dir after it has 
created the client with osync_client_new.

This would have the additional benefit of keeping the peer-specific (in 
this case: Mozilla-specific) code out of the OpenSync codebase.

So even though Thunderbird 2 and Thunderbird 3 are so different, that it 
seems I will have to create two different plugins, all this would be 
handled inside a plugin for Thunderbird, while keeping the mozilla-sync 
in OpenSync very slim.

Any comments and thoughts on this would be most appreciated.

/Henrik