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

List:       kde-core-devel
Subject:    Re: kmail status w/addressbook
From:       Don Sanders <don () sanders ! org>
Date:       2000-05-11 2:19:55
[Download RAW message or body]

On Thu, 11 May 2000, Waldo Bastian wrote:
> On Wed, 10 May 2000, 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.
> 
> Hierarchy? In groups you mean?

Hmm, to me 'groups' in an address book context is synonymous with 'categories',
and isomorphic to 'aliases', (that is creating aliases which are lists of people
is the inverse of deciding which category each person belongs in.)

By hierarchy I mean support for navigating a tree like structure of entities.

Strictly speaking there is a difference and it is important when dealing with
address books, but I often confuse the two concepts myself.

> > 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.
> 
> > Personally I would prefer to spend my time finishing off an address book
> > that meets more of the above requirements than porting KMail to use KAB.
> 
> Isn't it easier to add whatever is needed to KAB instead of creating a 
> separate standalone addressbook? 

I doubt it. Requiring support for groups and custom fields probably meant it
was easiest to rewrite a new AB backend. I wanted a completely different looking
front end so it was probably easiest to start that again from scratch rather
than basing it on the KAB GUI.

The irony of the situation is that the entire reason I started working on the
address book was that I was hoping it would act as a catalyst for encouraging
cooperation (and reduction of duplicated work) between the various email
application developers, I didn't think about the duplication of effort with 
KAB :-(

I should point out that the new KMail addressbook is not planned to be
standalone. It is planned that Empath/KMail use the same address book, Rik and
I are (I believe both intending to get back to) working on that together. Rik
wrote the backend/API I wrote the frontend/GUI we have yet to (successfully)
put them together yet.

> Maintaining two addressbooks seems like a waste of effort to me.

Having multiple front end GUIs, isn't a waste of effort any more than having
different styles of clothing is.  Ok so it is a waste of effort but people like
having a choice for some reason anyway.

You in particular do a ridiculous amount of maintainance on a huge
portion the KDE code base, so if you are coming from a I don't won't to
maintain even more code perspective that's a fair point.

Having multiple APIs that do the same thing is a problem. But last I looked KAB
doesn't support a hierarchy, or custom fields. (Actually the AB GUI I wrote
doesn't support a hierarchy yet either but it is planned, the problem was
making sure it didn't get in the way of people who wouldn't use it).


Anyway he who codes wins. If Mirko makes the enhancements I feel are most needed
to KAB and integrates it with KMail (without breaking stuff, same as Espen did
for the configure dialog) then I will lose motivation to work on the address
book and make it a lower priority. (I guess he could also code a new mail
client but I suspect htat would be more work).

I would just as much like to work on leave messages over x kb on pop server and
non-blocking smtp support as I would work on the addressbook. If some wants to
integrate KAB and KMail or better yet write a new KAB gui (that uses the
libkab as the backend) and integrate that with KMail I don't have a problem
with that.

I am somewhat ambivalent about which address book backend is used honestly.

BFN,
Don.

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