Hello Manasij, I'm not sure why would you want to include the glib header into your public header. All the GObject boilerplate can be placed into private files, and from gSSO point of view the only thing that is required from the plugin is that it provides a 'gsignond_<plugin-name>_plugin_get_type' symbol, which is resolved by gsso using g_module_open() and treated as a function that returns GType*. This symbol does not have to be in a public header at all.
Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of MANASIJ SUR ROY Sent: Wednesday, January 8, 2014 10:49 AM To: Macieira, Thiago Cc: [email protected] Subject: Re: [Dev] Inclusion of glib headers in Tizen Native public header files Hi Thiago, Thanks for your input. Initially I started the discussion in TSG-ARCH-API list (https://lists.tizen.org/pipermail/tsg-arch-api/2013-December/000049.html) - Please note that, the current approach mentioned does not require Tizen Native App developers to use glib-style codes. They just need to put one macro (something like say, SSO_PLUGIN_REGISTER(MySsoPlugin)), which wraps the required glib macros. (But yes, after macro expansion, it will be a mix code, and also putting a mandatory macro itself is not very common in Tizen Native) Please find below the detailed description of the problem and the alternatives we considered: - This is for "Single Sign On" feature for Tizen 3.0. We are going to adopt the open source gSSO as base. You can refer to https://lists.tizen.org/pipermail/dev/2013-December/001186.html for the initial discussion started by Jae-Hwa Shin. - Apart from other SSO features, we would like to provide Tizen Native APIs to write authenticator plugins/lib that can be loaded by gSSO (you can refer to http://gsignon-docs.accounts-sso.googlecode.com/git/gsignond/GSignondPlugin.html for getting an idea about the gSSO authenticator plugins). - The approaches we have considered so far: 1. Customization of gSSO (mainly the plugin loader module), so that we can define Tizen specific plugin interfaces. - Drawback: We need to modify the open source gSSO. 2. Creating ONE Tizen specific gSSO plugin and use this plugin to load all Tizen authenticator plugins. So basically this would have worked like a plugin loader, but without the need of modifying the gSSO code. - Drawback: As per current gSSO design, only one session can be active at any time for each plugin. Due to this, if we go by this alternative, then it will impose that only one Tizen Native plugin session can be active at any given time. 3. And lastly, the inclusion of glib headers as discussed in this mail. - Drawback: Tizen coding idiom violation. I will initiate the ACR process soon, so before that I wanted to discuss the same in the DEV mailing list. Please let me know your suggestions. - Thanks and Regards, Manasij Samsung R&D Institute India, Bangalore manasij.r AT samsung.com ------- Original Message ------- Sender : Thiago Macieira<[email protected]> Date : Jan 07, 2014 19:52 (GMT+05:30) Title : Re: [Dev] Inclusion of glib headers in Tizen Native public header files On segunda-feira, 23 de dezembro de 2013 05:16:38, MANASIJ SUR ROY wrote: > Hi All, > > We are going to adopt a glib based open source library for one of the > Tizen > 3.0 features. > > The open source core library is using plugin based architecture and we > wish to provide Tizen Native APIs to write plugins too. However we are > facing one conflict with current Tizen coding idiom standard in order > to achieve the same. I will describe the situation below: Hello Manasij This needs to be done with a lot of care. On one hand, I think that it's a great step to take something established and built upon it, rather than reinvent the wheel and take the risk of having unstable code. On the other, this is adding glib as a mandatory dependency for applications, visible to end application developers (if I understood correctly). The API styles clash badly with one another. If it's possible to mitigate it by not requiring the end developer have to know glib or write glib-style code, it would be a lot more palatable. Anyway, the decision is not mine. Since this is potentially quite big, I recommend you make a more detailed explanation and submit to the Arch Workgroup (the API change process). It would probably be interesting if you explained what the options are, what the cost and drawbacks for the other options would be, and how much this impacts the end application developer. PS: discussing in the mailing list is fine, but it looks like we need the big- picture-experts to approve it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center <p> </p><p> </p> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
