Settings are not updated to Accounts when saved in onAccountCreated function.
Moved Profile Id saving code to OnAccountEnabled signal.
Remove useless Logger includes sprinkled all over the place.
Using Qt methods to log output to stdout and removed logging to file

The Qt debug methods, qDebug(), qFatal() etc. are used to log the output
to stdout rather than to a file (using the Buteo message handler). This
choice is valid, since in production devices, it is not expected that
msyncd writes to files (which it does not in the prev. way too). In dev
environment, developers can start msyncd from cmdline and check the
output there itself, or redirect the ouput to a file. msyncd now does
not initialize the Logger::instance()

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
[packaging] contextsubscriber is a vestigal build dependency
Merge pull request #26 from stskeeps/master

[packaging] contextsubscriber is a vestigal build dependency
Merge pull request #23 from maninc/master

Settings are not updated to Accounts when saved in onAccountCreated function
[service] Add -o to invoker exec cmd
Merge pull request #27 from faenil/oom

[service] Add -o to invoker exec cmd
Created dbus interfaces for base plugin, client and server

The idea of creating out of process plugins is to create separate
processes for each plugin and use dbus to enable communication between
the plugins and msyncd. For this, the main interface methods for Plugins
are converted into dbus interfaces.

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
Created OOPPluginManager and the OOPClientPlugin and OOPServerPlugin

The OOPPluginManager is inherited from PluginManager to ensure the
side-by-side compatibality of in-process and out of process plugins.
Also, since the plugins are going to be out of process, the
OOPClientPlugin and OOPServerPlugin are going to act as d-bus interface
interaction instances to deal with the plugin processes. Next, the
methods in PluginManager have to be implemented to start process plugins

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
Modified the design. Removed OOPPluginManager

Realised that the PluginManager can handle both the dll plugins and the
OOP plugins. Added two maps for client and server oop plugins. These
maps can be used to keep track of the started/stopped processes

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
Added functionality to start, stop a client process plugin

Added functionality in the PluginManager to start and stop process
plugins. Did not want to modify PluginManager to a QObject unless and
until required. So made use of the waitForStarted() and
waitForFinished() methods to block the process startup, shutdown.

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
Created OOPClientPlugin and OOPServerPlugin implementation templates

The OOPClientPlugin and OOPServerPlugin instances using dbus to interact
with the process plugins that have been started by PluginManager. All
the signals/slots that are triggered because of the plugins or the
framework are handled by these classes and they inturn
marshall the messages and send them to the process plugins. Similarly,
for the messages received from the process plugins, these classes
unmarshall them and send the appropriate signals

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
Created OOPClient and OOPServer plugin objects in PluginManager

The integration of OOP plugin process is complete with the
PluginManager. Now the ClientPluginRunner and ServerPluginRunner will be
able to issue commands to the oop plugins

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
Created a plugin dbus interface file for client and server plugins

Removed the earlier separate client and server dbus plugin interfaces
and combined them into one dbus interface file. Generated the stubs and
skeleton for the same

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
Added method setPluginParams to set the initial params of a plugin

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
Added plugin_main.cpp that can be used by plugins to create binary

The plugin_main.cpp can be linked by plugins to create the needed
binary. Also modified the signature of the PluginServiceObj to include
the plugin name and profile name. The classname of the plugin has to be
set in the .pro file. The files PluginServiceObj.* and plugin_main.cpp
will be used only by plugins

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
Generated the stubs and skeletons for the newly added method in xml file

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
Completed plugin_main.cpp and also the outer shell for plugins

The plugin_main.cpp, PluginServiceObj.h and PluginServiceObj.cpp files
form a shell around a plugin to perform the communication between msyncd
and the plugin process. The only change that needs to be done in the
plugin code is to add an extra config for generating the exe and to
include the above files in the make. The syncmlclient plugin code has
been modified to prove this mechanism

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>
Added plugin name and profile name as arguments for starting oop process

Signed-off-by: Sateesh Kavuri <sateesh.kavuri@gmail.com>