Hello, a few additions from me:
- yes, with this approach you will be able to provide support for plugins that implement Tizen specific plugin interfaces and are written entirely using Tizen native libraries and frameworks , as long as those plugin interfaces conform to what gSSO is expecting from plugins (e.g. there should be an initial request, an intermediate request and response, a final response, a ui request and response, and so on). You would have to provide a Tizen specific plugin loader, the job of which is to translate the Tizen-specific plugin interface to dbus calls over stdio. - you can write such a plugin loader in two ways: a) modify the existing loader so that instead of loading glib plugins, it loads and makes calls to Tizen plugins. Jussi describes that approach below. b) write an entirely new loader using Tizen native code (or any other framework you wish to use). The only requirement is that such new loader should be able to perform p2p dbus communication over file descriptors - gsso daemon communicates with plugins using dbus over stdio. - we will make this dbus plugin communication API public, documented and (possibly) versioned. - at the moment gsso of course supports only one plugin loader. To support multiple plugin loaders, changes to plugin proxy code and plugin remote code are required, as you say, and how discovery of multiple plugin loaders works need to be documented. We can do that work so that you don't have to do it, and you can focus on doing just the Tizen-specific plugin loader and plugin headers/librarires/API definition. Let us know if something is still unclear, or there is something you disagree with. Regards, Alexander -----Original Message----- From: Jussi Laako [mailto:[email protected]] Sent: Wednesday, January 15, 2014 11:49 AM To: [email protected] Cc: Kanavin, Alexander; [email protected] Subject: Re: [Dev] Inclusion of glib headers in Tizen Native public header files 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
