On Friday, 2013-06-21, Jan Kundrát wrote: > On Friday, 21 June 2013 12:17:38 CEST, Pali Rohár wrote: > > So if addressbook plugin using client/server model (not only > > akonadi!), it can check if server is installed and enabled in > > isValid() method. > > And hence my remark about the LDAP server. The current draft of the API is > sufficient for checking whether Akonadi is available, but not whether a > remote LDAP server can be reached. > > I'm not saying that this is wrong per se, I'm just pointing out what the > current interface won't accomodate. BTW, I assume that there are also > other failure modes of Akonadi (like a botched MySQL setup, I guess, etc) > where the plugin returns "yes, Akonadi server will be available if > started", but where it will fail at runtime. > > Anyway, this particular use case which you call "client/server model" IMHO > applies only in these special cases where both cilent and server are on > the same machine and when you can check whether the server is there in a > negligible amount of time (otherwise you'd need an async interface to > avoid UI lockups). This *might* work for Akonadi (except that I'm not sure > how would you actually detect the server -- shipping a list of packages to > check the local DB? Discovery of binaries in $PATH? Both are completely > evil, and I have no idea how to do that in a different way), but I'm not > sure whether this is worth the effort. Surely we can expect that if the > plugin is available, the client libraries are there as well, and unless > the packager botched something, the server will be available as well, and > in the rare case it's not, we can resort to runtime errors.
Indeed, which is why I originally asked about the isValid() method. After Pali's answer I assumed it would be for plugins which just check for a local executable they would have to run through QProcess, e.g. commandline tool based addressbook. I.e. meaning that the Akonadi plugin would just always return true (it links an Akonadi client library, which will have Akonadi server as a package dependency). Anything else would require an asynchronous interface, potentially handling change (service becoming available or unavailable). My recommendation would be to keep the interface small at first and expand it later when there is a better understanding of various needs. After all it needs to be implemented at least twice (once for the current addressbook, once for KDE integration) and if ABI is of no concern right now than rapid prototyping is usually the better approach then trying to catch everything in the initial design. I.e. initial design should focus on things that are obviously problematic, like synchronous/asynchronous. Of course, by that measurement even a job interface is already a second iteration, but I do consider that an obvious thing to do when multiple request are expected to happen asynchronously ;-) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
