Hi,
On 15.1.2014 10:13, MANASIJ SUR ROY wrote:
I have few doubts regarding the same:
- Will it allow to have Tizen specific plugin interfaces? (i.e. instead of
gsignond-plugin-interface, can we use our own Tizen specific interfaces for
plugins?)
Yes, the plugin (.so) interface is implemented by the plugind, which is
interface translator and plugin loader. So the plugind is exec'd with
p2p dbus hanging on it's stdio descriptors. Then plugind needs to
implement the necessary dbus interface, all the rest is actually
business of the plugind.
Having the GObject based .so plugin interface is convenience, because it
is easier to make plugins with such interface. Originally the dbus
interface was intended to be private so that we could change it as
needed and even the fact that there was dbus in first place would be
hidden from plugin developers. What we are offering now is to open up
the dbus interface and support multiple plugind's because it is cleanest
way to do what you are asking. And it actually would be a nice feature
(one could even write a plugind in Python)...
- Only plugind customization is sufficient or it is required to modify
plugin-proxy, plugin-remote related codes (libgsignond-plugins) too?
If you are fine with plugind itself linking to glib, you can make your
own copy of src/daemon/plugins/plugind. To enable building plugind out
of the main source tree we'll probably have to move some of the
necessary sources to the gsignond-common library so that they are
accessible. Then you need to replace the calls that refer to
priv->plugin object in the handler callbacks with your Tizen plugin
interface calls and then handle the calls (or signals) from plugin (see
"Connect plugin signals to handlers" part).
https://code.google.com/p/accounts-sso/source/browse/src/daemon/plugins/plugind/gsignond-plugin-daemon.c?repo=gsignond
So the priv->dbus_remote_plugin would stay as-is, but priv->plugin would
be replaced with something Tizen specific. It is quite easy to bind this
kind of interface to a virtual C++ class. You can also just try-catch
exceptions and handle those as proper.
The main.c can stay as it is.
Alex can probably comment if I missed something.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
