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

List:       kde-pim
Subject:    Re: Grouping + importing
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       1999-07-21 22:05:25
[Download RAW message or body]

From: Rik Hemsley <rik@rikkus.demon.co.uk>
> Hi folks.
> 
> I've spent the last week trying to come up with a generic addressbook format.
> 
> This doesn't mean a new text file format, it means an OO model that provides
> the following features:
> 
> 1) Extensibility at all levels.
> 2) Easy access to all parts of addressbook entities.
> 3) Speed.
> 4) Import abilities through a plugin interface.
> 5) Grouping of entities.
> 
I have been working on the address book entry browser (ABEB) that lets a user
choose addresses from a list of entries. I have also fixed a few bugs in the
address book entry editor (ABEE).

I have been thinking about was has to be done for me to adapt this code to
your API, and also what the implications of handling large/remote and
"dynamic" address books would be.

Currently the ABEE uses a ContactEntry class which is basically a QDict. The
ABEB uses a ContactEntryList is basically a list of QDict.

I think this is a simple solution but not really a good one. The entire
addressbook is loaded into memory at startup. My ABEB GUI at the moment pretty
much relies on this, so it wouldn't be useful for handling a large/remote
addressbook (at least not one that consists of only one group). I guess
handling a large/remote addressbook requires minimising the amount of data
transferred and requires doing all the computationally intensive work on the
server.

I have begun to think about dynamic addressbooks. By this I mean addressbooks
that are shared between client programs. A situation similar to filesystems.
Currently the ABEB program loads up the entire addressbook. This is like the
filemanager loading up all the files on a device just to display them. (It's
fine as long as the device is small enough). We can handle larger addressbooks
by using directories to store the most important fileds of the address book
entries.

This does have its problems, for instance I would like the user to be able to
choose which fields are displayed in the ABEB.

There is also the issue of whether/how the ABEB view should be updated when
another client modifies teh address book 'database' the enduser could be
required to manually refresh the view, (The outlook express ABEB seems to take
this approach), alternatively CORBA could provide a nice network transparent
soln to this.

So as far an "OO model" goes I have these concerns:
A) I think a QDict like interface with methods like
ContactEntry::insert( QString field, QString value )
ContactEntryList::defaultFields( QStringList fields )
is the most natural for AB clients like the GUI stuff I have been doing.

I'm not convinced that your second objective
2) Easy access to all parts of addressbook entities
has been achieved, rather I think
2*) Easy access to all parts of vCardd address book entities
has been achieved.

I think your API is an excellent vCard API but I am not convinced it is the
most natural AB API. (Note basically this just means a QDict to vCard mapping
is required, this has to be done at some point regardless, the question is
when, I thinking a ContactEntry -> vCard Entity mapping needs to be written,
I'm willing to do this but I need to compile your stuff first and will
probably ask for help/clarification on some fields)

B) Have you given any though to dealing with large/remote address books, I'm
thinking of dealing with this later. I think a whole new API and modified GUI
is need to handle this
(eg. server give me records x to y when sorted by field abc)

I thinking the best way to handle addressbooks is to assumme that they have
been broken up into sensible size folders/groups and load all entries in a
folder at once, (so that an arbitrary set of fields can be displayed). Perhaps
this could be optimized by providing a method that returns all subfolders in a
folder so that a explorer like tree control for navigation could be provided.

C) Dynamic updating
Does you model deal with this? I can see several different solns, require the
user to manually update, chunky updates where the entire AB folder is reloaded
whenever the AB is modified, or finer updating incrementally handling
insertions/deletions and only refreshing/resorting modified entries.

Other issues:
Import abilities through a plugin interface sounds damn cool.

You are using namespaces. I'm using egcs 1.03 at the moment and will have to
upgrade before I can compile your code.

My UI doesn't support all vCard info. For instance your sample vCard contains
the line
EMAIL;TYPE=INTERNET: rik@kde.org

currently my UI just has email, email-2 and email-3 fields. The draw back here
is that if someone edits the sample vCard in my editor they will lose the TYPE
inforamtion, and I can't handle more than 3 email fields. Also the entire TZ
field will be lost as the GUI doesn't currently support it. (Perhaps I could
automatically put this in the Custom fields tab).

Okay I hoped that made sense. By all accounts you have implemented an
excellent vCard API but I think more discussion needs to take place regarding
the AB API.

BFN,
Don.

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