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

List:       kde-core-devel
Subject:    Re: kmail status w/addressbook
From:       Mirko Sucker <mirko.sucker () unibw-hamburg ! de>
Date:       2000-05-12 22:57:15
[Download RAW message or body]

Don Sanders wrote:
> 
> Off the top of my head this is what most people want in an email client address
> book.
> 
> GUI
> Can enter name and email address EASILY.
> Should be able to create email aliases for a list of email addresses.
> Should be able to organize email addresses into a hierarchy.
> Supports a variety of fields (which and how many depend on the individual user,
> some people want customizable fields)
> Easy to use and powerful search facility.
> Good printing and export (including to html) support.
> Can customize which fields are shown.
> 
> Backend
> Good search API including fast auto-complete email address support.
> LDAP support.
> Import/Export from Notes,Eudora,  MS Outlook and MS express.
> 
> Last time I looked KAB fell short in several areas. I'm not against adding KAB
> support to KMail, but I think it should only be one possible option.
You looked from the wrong perspective.

TOP 1 - Enter name and email address easily:

You do not need to use the kab GUI to do it. Just use a two-line dialog,
or better, use name and email address from an incoming mail and add it
to the address book. 
When selecting an address, just pick one from the database like in
kabapi_test. 
When implementing auto-complete, get all email addresses from the
database and put it into one list for the possible values.

TOP 2 - Email aliases:

This is a matter of perception - to kab, each entry is an alias for
different mail addresses. The only usefull addition would be to make one
entry (perhaps a person) an alias of another. 
To aggregate different mail addresses of one recipient, use one entry
with all the mail addresses.

TOP 3 - Email addresses in hierarchies:

I do not see the sense. Is this meant like grouping? 
Grouping is prepared in the design of kab´s database, but not
implemented. I plan to add a hierarchy of groups beside the entries and
assign each entry to a group. 

TOP 4 - Variety of fields:

kab supports all fields wanted by users in the last two and a half year
plus (currently) up to four user fields that may be named as needed.

TOP 5 - Easy to use, searching:

Matter of taste.

TOP 6 - Printing, exporting: 

A matter of the front end. You might easily implement a printer program
for the address database independantly from kab. This is no task for the
mailer program.

TOP 7 - Customize display:

I am in the last stages of creating a view for kab using HTML (QML)
templates modifieable by the user using some special tags.

TOP 8  - other stuff:

- searching is a matter of the client using the API, but might be
included easily. But note that the API will get larger  - one of the
goals after KDE 1x was to get it as lean as possible.
- LDAP is something different. It would be an idea to add LDAP searching
to the KABApi class, but the local storage is needed anyway, since you
have to consider 1. the "own" addressbook of the user and 2.
non-permanent network connections. 
- Import and export filters are client programs to the library. I often
applied for people being able to do that. There are none, by now. 

--------
This is to show you that there is a lot of potential functionality in
the library.

Now is it worth rethinking to demand for a new one?

--Mirko.
-- 
Drei Dinge gibt es, denen alle Menschen gern gemütlich zuschauen:
° fliessendes Wasser,
° knisterndes Feuer und (am allerliebsten)
° anderen Menschen beim Arbeiten. (Charlie Brown).

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