[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Moving new address book API to kdelibs
From:       Mirko Boehm <mirko.boehm () home ! com>
Date:       2001-10-31 3:41:57
[Download RAW message or body]

Stephan Kulow wrote:
> 
> On Tuesday, 30. October 2001 04:02, Mirko Boehm wrote:
> 
> >
> > Sorry, Cornelius, but I think rushing in with something definitly not
> > mature is the wrong way.
> >
> 
> Hmm, we're freezing features, not code. If it isn't mature enough yet, we can
> fix this. libkab definitly shows it's age and you don't seem to be available
> to fix it. And the thread around kabc showed that people want a new API.

The point why I did no more changes to libkab - and I expressed this a
few times ago - is that there where approaches to replace it, with most
effort by Rik Hemsley. I know about its limitations, but hey, what
better is what is to come? It replaces what we have with something that
does nothing more and creates a lot of problems implementing all
features we had as the backend format does not support everything. 

The new API does not solve the incompatibilities between kaddressbook
and kab. 

It is not even a concerted effort of the developers involved. 

It does not address interoperability issues between organizer and
contact APIs. 

Using vCards as backend does not help to solve the synchronization
problems as we still have file based accesss. See: if we have n
applications storing PIM data and m external devices (like palms, cell
phones, whatever) we create m*n synchronization conflicts. That is why I
always opted for a DCOP based "server" approach where a central instance
keeps track of the data. This reduces the conflicts to O(n) instead of
O(m*n) (rather simplicistic, but still correct). 

You see, there are points about it. We will have to debug it.
Applications will have to be ported. For what? There is no new feature.
We do not want the users to have to do decisions about the backend
format (so why either vCards or config files? Who is about to decide?)
libkab might be old and its approach is not elegant. Right. But the new
one is still file based (so - not elegant either) and lacks some
features kab users liked for YEARS now (like multiple addresses per
person - sorry, I added this on users request, even if it sounds
complicated on the first glance). 

My point is: 
- if we do not support everything the old API supports we piss off users
- using standard formats as backends does not gain anything as we do not
want the users to deal with the files stored in obscure places, the
interface (library or process) has to handle data exchange
- we still do not integrate the different PIM applications 
- compared to MS Outlook or Lotus Notes, everything we do on the address
library is irrelevant and looks poor, we simply lack a common approach
on doing things


I do agree work has to be done on the contact database issue. What I
tried to convince Cornelius in a verbose email conversation and here on
this list is - this approach does not lead us to anything the users will
feel or recognize. Nobody cares about file formats. 

To be honest - I feel sorry I did not push the development of libkab.
But I did not want to work on something "about to be replaced" (what is
its status for close to 3 years now). But if is has to be replaced the
replacement has to be the "third system" (what is supposed to be as
elegant as kwin's approach), since the current version is already the
second system that resolved some issues and incorporates the expirience
from a lot of user responses and requests.

I do not get mad if my code gets replaced. I just think I know something
about the topics involved, and I got the feeling the matters where not
taken seriously into consideration. What are you going to tell the user
that uses parts of his contacts for a file format change he never sees?

CU,

--Mirko.
-- 
I am wrong.

[prev in list] [next in list] [prev in thread] [next in thread]