[Dev] Inclusion of glib headers in Tizen Native public header files
alexander.kanavin at intel.com
Thu Feb 20 12:57:16 GMT 2014
I'm not very familiar with Tizen app controls (just had a quick look at
the documentation), but I think there is no issue - if you can express
the gsso plugin API in terms of the app control API.
Gsso requires the following from the plugin loaders:
1) listing available plugins on standard output with --list-plugins
2) with --load-plugin=name, a plugin d-bus object should be exported on
a communication channel made of standard input and standard output
streams (you can reuse the code from the default loader for this). Any
diagnostic and debug messages should go to standard error.
3) plugin loader should shut down gracefully when a SIGTERM signal is
sent to it.
Anything else that happens in the plugin loader is invisible to gsso,
and you can decide what is the best solution for loading plugins and
communicating with them. If Tizen app controls is the best mechanism,
then that's fine.
Also note that for many types of accounts, it is not necessary to write
an authentication plugin - if the service is using OAuth, or SASL, or a
simple username+password-based login, then it can simply use gsso's
standard plugins, and providing just the account CRUD module is enough.
I can imagine that custom authentication plugins would be needed for
proprietary things like iTunes or Skype, or other services with
non-standard auth protocols.
On 02/20/2014 10:19 AM, MANASIJ SUR ROY wrote:
> Hi Alex,
> Thanks for sharing the multiplugin code.
> From the code I can see that "--list-plugin" and "--load-plugin" options have been added for plugin loader daemons. So I think plugin loaders can decide the type of the plugin file? (i.e. to use .so or .exe)
> The reason we are evaluating .exe as authenticator plugins are:
> 1) Tizen mandates the API level access control for security sensitive operations(Privileges). For .so, it is the responsibility of the loading application/process to have the privileges required by the .so.
> In our case it will be plugind, which can not know the list of privileges required by the authenticator plugins beforehand.
> 2) Tizen::Social namespace has "Account" module which lets 3rd party developers to create app controls (.exe) for doing CRUD on Tizen accounts.
> We can integrate SSO functionalities with these app controls so that they dont need to deploy one .exe (for Tizen::Social Account) and one .so (for SSO).
> So we would like to know, from gSSO's point of view is there any issue if plugins are .exe instead of .so?
> - Thanks and Regards,
> Samsung R&D Institute India, Bangalore
> ------- Original Message -------
> Sender : Alexander Kanavin<alexander.kanavin at intel.com>
> Date : Feb 17, 2014 22:57 (GMT+05:30)
> Title : Re: [Dev] Inclusion of glib headers in Tizen Native public header files
> Hello Manasij,
> the multiple plugin loader support in gsso has been completed and
> published here in the multiplugin branch of gsso:
> We still need to review the code, merge it into the master branch,
> update the online documentation and release the new version into Tizen
> repositories, but you can check out the code from git and play with it
> already now on your local machine. The topmost commit adds the
> documentation about how it works :)
> Let us know if there are any issues etc.
> On 01/31/2014 02:35 PM, MANASIJ SUR ROY wrote:
>> Hi Jussi, Alex,
>> With the approach you mentioned, I am able to create a sample Tizen Plugin Loader and able to communicate with both gsignond and Tizen plugins.
>> I will keep watching /profile/ivi/gsignond and accounts-sso google code repo for the official release and docs regarding the support of multiple plugind's.
>> Thank you for the help.
>> - Manasij
>> Samsung R&D Institute India, Bangalore
>> manasij.r AT samsung.com
>> ------- Original Message -------
>> Sender : Alexander Kanavin<alexander.kanavin at intel.com>
>> Date : Jan 15, 2014 19:45 (GMT+05:30)
>> Title : Re: [Dev] Inclusion of glib headers in Tizen Native public header files
>> On 01/15/2014 01:26 PM, Kanavin, Alexander wrote:
>>> 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.
>> By 'stdio' I mean the standard input and output streams that Unix
>> processes are provided with, not the stdio.h facilities :)
>>> 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
>> Same here. Read 'standard input and output' instead of 'stdio'.
>> <p> </p><p> </p>
> <p> </p><p> </p>
More information about the Dev