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

List:       kde-pim
Subject:    Re: [Kde-pim] Suggestions for libkabc
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-06-10 22:15:30
[Download RAW message or body]

On Monday 10 June 2002 20:53, Tobias Koenig wrote:
>
> since we didn't get finish with the libkabc API/feature discussion at
> LinuxTag, I want to continue it here.

That's very good. We will have to come to a list of features we want to 
have implmented for KDE 3.1.

> ATM there are 2 main problems:
> 1) We need a valid revision tag for working fine with kitchensync
> 2) The resource managment is not satisfying
>
> 1:
> libkabc supports the REV tag in vCard now but there are problems with
> the applications using the library.
> Normaly a new or changed Addressee is insert in the address book with
> 	AddressBook::insertAddressee( const Addressee& )
> in this method we check if it already exist and replace the available
> addressee with the new one (+ set revision date/time).
> The problem is, it only works when a copy of the original Addressee
> is insert in the AddressBook.

Why? The revision is the date of the insertion. There shouldn't be a 
difference, if an existing entry has changed or a new one has been 
added. What's the problem here?

> Furthermore we have to extend above mentioned method to
> 	AddressBook::insertAddressee( const Addressee&, bool newEntry =
> false )
>
> newEntry is set to 'true' when e.g. kaddressbook insert a new created
> addressee. Only with this parameter we can distinguish if a existing
> addressee from a resource is insert or a completly new created.

But the AddressBook knows which entries it contains, so it shouldn't be 
necessary to pass this information from outside. For what purpose do 
you need this information anyway?

> 2:
> I would like to see LDAP and SQL resources in libkabc, since it was a
> frequently requested feature at LinuxTag-PIM-Booth.

LDAP would be very nice. I think SQL isn't as important as LDAP, because 
there is no standard database scheme to store contact information and I 
don't think we woul dgain very much from a database backend in the 
current stage of libkabc.

> So the questions is how to provide a clean, extensible and fast API.
> On the homeward journey some ideas come to my mind...
>
> Addressee:
> 	- gets the booleans isDeleted and isChanged
>
> Resource:
> 	- gets the booleans useInQickSearch, isMainResource and isReadOnly
> 	LDAP: gets a search filter
> 	SQL: gets a search filter
>
> When a application uses StdAddressBook, StdAddressBook checks for all
> resources, that should be loaded, set them readOnly (if set in config
> file) and calls the load method of them.

This makes sense.

> In kaddressbook all resources would be loaded and in KMail only the
> resources that are marked as 'useInQuickSearch'. So every use can
> decide if a LDAP or SQL resource is to slow for him for use in KMail.

Hmm, I don't think that we can determine automatically what resource 
objects are usable in a quick search. This depends on the number of 
entries and the way how the resource is accessed. Or do you mean the 
user should manually select which resources are considered to be 
"quick".

> The resources check for their configuration files, load either all
> Addressees they can access (would be the case with VCard and Binary),
> or load only all Addressees that matches the filter (LDAP and/or
> SQL).

But how do you set up this initial filter? When KAddressBook is started, 
you don't know which addresses the user will query from an LDAP server. 
I think it doesn't make sense to "load" an LDAP addressbook. For the 
LDAP case only the find* functions of AddressBook make sense.

> When calling removeAddressee(), the Addressee is not really removed,
> only marked as 'isDeleted'.

What's the benefit from not removing the addressee at once?

> Only the resource that has the isMainResource bit set, is allowed to
> save the new Addressees.

Wouldn't it make sense to have multiple writable resources? KAddressBook 
would have to determine to which resource a new entry would have to go 
by opening a small dialog or something similar before creating a new 
addressee.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]