[kdepim-users] KDE SC 4.4.0 and address book (solved)

Ingo Klöcker kloecker at kde.org
Sun Feb 28 11:49:14 GMT 2010


On Sunday 28 February 2010, Werner Joss wrote:
> Am Sunday 28 February 2010 11:41:52 schrieb Ingo Klöcker:
> > You mean, what is the limitation of a local vCard file used via the
> > compatibility Akonadi resource (i.e. "KDE Address Book
> > (traditional)") opposed to a local vCard file used via the new
> > native Akonadi resource (i.e. "VCard File")?
> 
> yes.
> 
> > I do not know the details, but does it really matter? It should be
> > rather obvious that using a compatibility layer is subpar to using
> > a native layer because
> > a) it adds a level of complexity, i.e. another point of failure,
> > and b) the compatibility layer adds compatibility for all of the
> > KDE resources supported before Akonadi and thus cannot be tailored
> > specifically for the needs of a single case.
> > 
> > I see only one reason why one would prefer the compatibility
> > resource over the native resource: If the native resource has a
> > bug which does not occur with the compatibility resource. To my
> > knowledge this is not the case.
> 
> there might be others, too.
> see my other post on the ubuntu-one/dropbox issue.

No, this doesn't appear to be an issue.


> sure, I could just host the native akonadi ressource folders
> (~.local/share/contacts/ ...) on a dropbox/ubuntu-one share,
> but that would result I could not use this directly from kde 3.5.x
> machines.

That's not true. ~.local/share/contacts/ is nothing else but a folder 
containing containing individual vCard files. This is exactly the same 
as the "local folder" resource supported by KDE SC 3.5.

But you do not have to. You can also simply create a VCard File address 
book and use this with Akonadi and KDE SC 3.5.

I think you are a bit confused by all this new stuff and this is fully 
understandable for anybody who does not follow the development as 
closely as I do. I'll try to solve a bit of your confusion.

KDE SC 3.5 supported (via the KDE Resources framework) address books 
stored in many different ways, e.g.
- a vCard file
- a folder containing individual vCards (one per contact)
- on an IMAP server
- ...

Akonadi supports address books stored in (not yet many) different ways, 
e.g.
- a vCard file (via a native Akonadi resource)
- a folder containing individual vCards (one per contact) (via a native 
Akonadi resource)
- on an IMAP server (via the compatibility Akonadi resource)
- everything supported by the KDE Resources framework (via the 
compatibility Akonadi resource)

What does change with Akonadi?
For the developer: A lot. Akonadi is a whole new way to access PIM data.
For the users: Basically nothing. Maybe the terminology used in the 
applications will change a bit, but we try not to expose technical terms 
in the user interface.

In particular, what does not change with Akonadi is the actual storage. 
Akonadi is no storage. It is very often confused with a storage. But it 
is no storage. Akonadi is a layer between the storage (vCard file, 
folder with vCards, IMAP folder) and the applications.


> as a side note, the DIMAP/kaddressbook ressource approach
> still doesn't work for me, although I tried the latest advice on
> userbase on that topic.

Okay. There can very well still be bugs. I have not looked into this 
issue as I'm currently not using DIMAP. In fact, I have disabled my 
unused DIMAP address book and calendar because I had problems with 
Akonadi starting KMail (or actually Kontact, but I patched my 
installation to start KMail instead) and KMail wanting to start Akonadi. 
Because of this the first start of KMail always failed. The second start 
(when Akonadi was already running) succeeded. This cyclic dependency was 
always there and it's one of the major issues that will be solved by the 
Akonadi port of KMail.


> plus, that would also imply I cannot easily
> access my contacts when I have just web access in an internet cafe
> (which is usually via internet exploder on a windoze box), same goes
> for windoze @work.
> the dropbox/std.vcf approach still works relative well in this case.

And this will never change. Not with Akonadi. And not with any latter 
changes. Rest assured that simple vCard files will always be supported 
by KDE.

I hope I could eliminate some of the fears you seem to have because of 
Akonadi.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20100228/4b0e2e36/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
kdepim-users at kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users


More information about the kdepim-users mailing list