Comment 3 for bug 1602159

You don't have to use a different API in the unconfined process: just do something like

  for (const QString &applicationId: supportedClients) {
      OnlineAccounts::Manager manager(applicationId);
      auto accounts = manager.availableAccounts();
      for (Account *account, accounts) {
          ... do stuff ...
      }
  }

The API can (and has been designed to) be used by unconfined clients, but always under the assumption that the unconfined client is acting on behalf of a proper click application, with its own ID and .application and .service files generated by the click hooks.

Now, I've given another quick review at the D-Bus API and at your MP, and I couldn't find any place that would break with your patch. The assumption that one click application/scope cannot use more than one service for the same account still holds, but that's enforced by the new click hooks, while the service and library can -- at first sight -- deal with multiple services, if your patch is applied.

Of course, given that I've kept that assumption in mind while writing the project, it's likely that there might be other places which break, and that your test case didn't uncover. It's for this reason that I'm hesitant to accept this.

So, my suggestion is to go with the pseudo code above. If for some reason that's not suitable (please explain), I'm ready to accept your patch, provided that it's landed in a single silo along with your project (so that we have a better confidence that this is the only needed changed, and that there aren't hidden dragons).