KDE/KApplication problems on Opensync
When trying to make a KIO plugin for Opensync, I (Eduardo Habkost) have hit some problems related to the behaviour of KApplication. Armin and me have discussed this problem. Part of the log is below.
The problem
Some plugins need to run on the main thread. Examples for these are mozilla thunderbird, kde and evo 1.4. The cause for this need are different. In the case of mozilla we have to connect to a already running thunderbird process to sync. With kde the problem is that a KApplication object gets created which can only be used from a single thread. So i you use a KDE gui (which creates KApplication) and then call kde functions from another thread, it wont work.
Solution
The solution is to make it possible to plugin to run in a different process and then communicate with opensync over a IPC. The problem here is that we have to marshal all communication with the plugin.
There are 2 possible points where the ipc communication could take place:
- replace the message bus between the engine and the client with an ipc aware bus
- send only the communication with the plugin itself over the ipc bus
The advantage of the first approach would be that it is nearly transparent up to a certain level.
The problem with the first approach is that you also have to marshal access to the member and the group (like get/set slow-sync) and it would be difficult to control this.
Another problem is the activation of the client process. If this process is started before opensync (like thunderbird) it would be really hard for opensync to locate the ipc.
The second approach would work like this: The plugin which wishes to have its own process would implement a activation plugin which only has the initialize function filled in. In this initialize function the plugin locates the ipc and connects to it. Then all other function calls (like connect) are intercepted by functions from the ipc object that marshal the call and sends it over the ipc. The ipc object and the other side unmarshals it and call the function on the real function and sends the result back. The advantage here is that we can leave it to the plugin author to decide how to locate or activate the ipc. We also have to marshal far less objects.
There also is a general problem: We can only send "plain" changes (changes which have format that dont have any pointers) since the pointers would get invalid of course (unless these formats would provide a marshal/unmarshal function).
-- EduardoHabkost, 16 Jun 2005, 11h13 (initial version)
-- Armin Bauer, 25 August 2005, (updated)
