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

List:       kde-pim
Subject:    Re: [Kde-pim] Suggestions for libkabc
From:       Tobias Koenig <tokoe82 () yahoo ! de>
Date:       2002-06-11 16:09:50
[Download RAW message or body]

On Tue, Jun 11, 2002 at 12:15:30AM +0200, Cornelius Schumacher wrote:
> 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.
Do we have to implement this features in 20 days, or do we have to
decided what feature should go in?

> > 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?
It is a problem with references. When not passing a copy of the
changed addressee to AddressBook::insertAddressee(), the Addressee==operator,
that is used in this method, compares the original addressee with the
original addressee and not the original with the changed. So the ==operator
returns always 'true' => revision is not set, since the addressee seemd to
be not changed.


> > 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?
insertAddressee is called twice:

The first time, when a resource add all his addressees to the addressbook.
In this case no new addressee (new = added by user in GUI) is insert =>
revision tag is not updated

The second time, when a user add or change a addressee in the GUI
(e.g. kaddressbook). In this case we have to update the revision tag.

Checking if the addressee, that is insert, has changed is no problem.
But how to differ between the first and the second case?
You know what I mean?

> > 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.
There were 3 people at the booth, which ask for a SQL backend :)

> > 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".
Yepp, they should be able to configure it in the KControl module.

> > 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.
Normaly you don't have to query the whole addressbook of a company,
only a small part of it (e.g. all entries of a department, all entries of
a project you are working in etc.)
So you can preselect a number of addressees that should be loaded in
kaddressbook. For single addresses, that do not match the filter, but
are used frequently, the user can add them manually to it's local addressbook.

> > When calling removeAddressee(), the Addressee is not really removed,
> > only marked as 'isDeleted'.
> 
> What's the benefit from not removing the addressee at once?
?!? Ok, then the resource class needs a 'removeAddressee' as well.

> > 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.
Ok, have no problem with it...

So if nobody objects, I'll collect all features and add them to the feature
plan.

Ciao,
Tobias
-- 
In a world without walls and fences who
needs Windows and Gates???
_______________________________________________
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]