On Wednesday, 2013-07-10, Pali Rohár wrote: > On Monday 08 July 2013 19:56:54 Kevin Krammer wrote:
> > If you want to display the plugin that has become unavailable > > you could additionally store the name, no? > > > > The main problem with using the identifier as a user visible > > string is that it is a foreign collection of symbols for > > anyone with non-latin script. > > Ok, I changed code to store also description of prefered plugins > to config file. Now only description is visible to user and name is > only internal identifier. Patches pushed to my merge branch. ok, great! > > Sure, there is no need to use Akonadi for a vcard addressbook. > > I was talking about the KDE addressbook integration :) > > > > Additonally, as I wrote above, using KABC::AddressBook is, > > first, an unnecessary overhead for handling a simple vcard > > file and, second, at some point just a compatibility API on > > top of Akonadi. > > This plugin has suffix traditional. KABC::AddressBook is not > limited to VCard directory, it also support other (remote) > storages. Because it using KABC library for addressbook which is > still part of KDE, I put it to KDE subdir. Hmm. I guess I am not writing it understandbly enough, let me try a different phrasing :) KABC::AddressBook is one of the frontend APIs of the KResource framework. The KResource framework has been deprecated a couple of years back, backends being gradually reimplemented in terms of the Akonadi client framework. It is already possible to build without KResources using a build time configure switch, but of course due to API and ABI compatibilty guarantees this is not applied on distributions packages until the next major revision. However, developing something against a deprecated framework is usually a waste of time, but at least needs to be done with understanding of the consequences. 1) Anyone with a KDE setup started with 4.4 or later will either not have addressbook access through KABC::AddressBook or through a compatibility plugin 2) KABC::AddressBook, while staying available as an API (see above), will be implemented in terms of the new framework once the new framework has reached backend availability equality. Then only backend accessor in KABC that is currently not available yet in Akoandi is LDAP addressbook. A prototype is being worked on right now, my guess is it will be releasable for 4.12. Whether KABC::AddressBook will be implemented directly using the new access framework or whether the existing compatibility plugin will be used is not yet decided as far as I know. My guess is the latter (already exists only trivial change to resource factory required). In my initial assessment I was assuming that the goal of the KDE plugin, especially in the context of the GSoC project, was to enable users of Trojita and using KDE PIM for addressbook to access addressbook data in Trojita. Most of those users will like not run something old as RHEL6 or Debian oldstable, but more likely something like recent Kubuntu, OpenSUSE, Fedora, Debian, etc. Creating a plugin for really old distribution versions or RHEL6 (or older) might be a worthwhile goal on its own, I am just not sure it should be the done as part of the GSoC scope. Do we have any opinion on that from the Trojita developers? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
