[Dev] libcynara API

Schaufler, Casey casey.schaufler at intel.com
Mon May 19 19:18:58 GMT 2014


> -----Original Message-----
> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> Sent: Monday, May 19, 2014 12:05 PM
> To: Schaufler, Casey
> Cc: Lukasz Wojciechowski; dev at lists.tizen.org
> Subject: Re: [Dev] libcynara API
> 
> On Mon, 2014-05-19 at 16:19 +0000, Schaufler, Casey wrote:
> > Please supply an example. A real one. From Tizen. Let's not go off
> > into yet another hypothetical discussion about how things ought to
> > work, or what problems we might encounter. We have more than enough
> > work to do without building interfaces for cases we are not actually
> > using.
> 
> Okay. Here's abbreviated code from PIM Manager in Tizen IVI which grants
> clients access to the unified address book. Some of these clients might be
> less privileged third-party apps who need do get granted access to contact
> data.
> 
> void Manager::search(const boost::shared_ptr<
> GDBusCXX::Result1<GDBusCXX::DBusObject_t> > &result,
>                      const GDBusCXX::Caller_t &ID,
>                      const boost::shared_ptr<GDBusCXX::Watch> &watch,
>                      const std::vector<LocaleFactory::Filter_t> &filterVector,
>                      const GDBusCXX::DBusObject_t &agentPath) {
>     // Start folks in parallel with asking for an ESourceRegistry.
>     start();
> 
>     LocaleFactory::Filter_t filter;
>     filter = filterVector;
> 
> 
> EDSRegistryLoader::getESourceRegistryAsync(boost::bind(&Manager::search
> WithRegistry,
>                                                            m_self,
>                                                            _1,
>                                                            _2,
>                                                            result,
>                                                            ID,
>                                                            watch,
>                                                            filter,
>                                                            agentPath)); }
> 
> void Manager::searchWithRegistry(const ESourceRegistryCXX &registry,
>                                  const GError *gerror,
>                                  const boost::shared_ptr<
> GDBusCXX::Result1<GDBusCXX::DBusObject_t> > &result,
>                                  const GDBusCXX::Caller_t &ID,
>                                  const boost::shared_ptr<GDBusCXX::Watch> &watch,
>                                  const LocaleFactory::Filter_t &filter,
>                                  const GDBusCXX::DBusObject_t &agentPath) throw() {
>     try {
>         if (!registry) {
>             GErrorCXX::throwError(SE_HERE, "create ESourceRegistry", gerror);
>         }
>         doSearch(registry,
>                  result,
>                  ID,
>                  watch,
>                  filter,
>                  agentPath);
>     } catch (...) {
>         // Tell caller about specific error.
>         dbusErrorCallback(result);
>     }
> }
> 
> 
> These methods execute from top to bottom. The first one is the main entry
> method, called directly by the D-Bus binding after parsing parameters of the
> method call. Information about the caller is available there.
> 
> Creating the EDS registry can take some time, which is why it is done
> asynchronously instead of blocking the process. The search then continues
> when the registry is ready and the searchWithRegistry() callback gets invoked
> from the main event loop.
> 
> This normal event driven programming.
> 
> Where do I put cynara_check()? If I do it in Manager::search() when called by
> client A and Cynara needs to ask the user before replying, processing calls or
> data from an authorized client B will stop during that time.
> 
> I can't spawn a thread either to handle the call, because libcynara is not
> documented to be thread-safe. I don't want to make assumptions about
> what I may or may not do with threads.

You can count on libcynara being thread safe.
 
> I'll stop here, because that's the show-stopper for me.

OK, that's all you needed to ask.

> --
> Best Regards, Patrick Ohly
> 
> The content of this message is my personal opinion only and although I am an
> employee of Intel, the statements I make here in no way represent Intel's
> position on the issue, nor am I authorized to speak on behalf of Intel on this
> matter.
> 
> 



More information about the Dev mailing list