https://bugs.kde.org/show_bug.cgi?id=323455
--- Comment #22 from Andreas Hartmetz <ahartm...@gmail.com> --- So yeah, the filters are loaded as soon as the Akonadi server reports that it's running. Or rather, as soon as Akonadi::ServerManager reports that the server is running, because there is no explicit interface for server status (which is IMO a problem). ServerManager reports the server as running if the server interface is present on DBus, the "updating interface" isn't (that one's OK, the updating interface is published before the main one so no race condition), and... ONE resource is running. That part is, well, basically, outright wrong. I don't see which client of the "running" API would be happy to consider the server as running if it has one out of n resources running, as opposed to none or all of them. The problems for fixing this are: - Determining which resources (agents) should be considered necessary for running status. Obviously broken ones (like agent binary not installed) shouldn't be, for example. This probably needs a status interface in the server because it's the only one that is supposed to have the information about the agents that *should* be running. (It could be derived from config files if all else fails, though.) - There should probably be a fallback to consider the server "running but with some broken resources", I'm thinking of 30-45 seconds. It would trigger for not obviously broken (see above) resources that still don't come up. That probably *will* cause bug reports from people who, for example, weren't using filters, so they would have been more or less OK before, but will have to deal with a now very slow starting KMail. Actually, after this thinking out loud session, KMail does know which agent IDs it wants to see, so I could create a somewhat quick and dirty fix to consider the server as running, for the purpose of filters, once these agents are present (with a timeout). -- You are receiving this mail because: You are watching all bug changes.
