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

List:       kde-pim
Subject:    Re: - Project Status report -
From:       Mirko Sucker <mirko.sucker () unibw-hamburg ! de>
Date:       1999-07-12 22:31:27
[Download RAW message or body]

Sorry, this mail went to Rik only. Here it is:


Rik Hemsley wrote:

> Hi folks.
>
> Well, I don't know if this will become a common feature, but I for one
would
> find it useful if we could produce a status report every so often.
'when
> appropriate' is probably the best timing, rather than fixed to every
week/month
> or whatever.
>
> Ok, here goes:
>
> Since this project started, we've managed to get a few people to
subscribe to
> the mailing list. Discussion has been very productive so far. The only

> problem is that there's basically only Rik and Don doing work so far.
On the
> bright side, at least we have some people on the list to comment on
things
> before we rush headlong into them. Notably absent: Mirko Sucker, Sven
Guckes,
> Stefan Taferner (possibly too busy).

You are wrong :-)
Hello guys,

I did not comment anything on the list until now, as I am currently
moving to a
new
flat and I am very busy...

But now, here are my comments. Please read until the end of the message,
to see
kab's future plans.

> kab hasn't been looked at hard enough to determine what needs to be
done to it.
> Rik has had a quick hack on it to see if he can convert all STL to
QTL.

Why do it? It has been a great advantage to use the STL, and I do not
think that
QTL is a good idea at all. Its only advantage is that it is part of Qt
(what I consider to be NO advantage, since QT is a user interface
toolkit, no
container/algorithm/adapter library).

     -------- Addressbook UI ------------
     It looks like we're pretty much agreed that the kab UI is pants and
should be

     replaced in some way.

This is simply not true. It depends on how you look at it. You want to
design a program like outlook, that integrates nearly all ideas of
self-organization.
kab is suited as a small, fast and nevertheless powerful tool to have
your
contacts on the desktop. For this goal, its user interface is fitting
well.
If you want to have a different user-interface to kab, you should have a
look at
the kab application (not the library). It shows that the complete user
interface
is
only an application of the kabapi.
So, if you want a new GUI for the addressbook, simply create a new
application
and link it libkab (but see the notes on libkab below).

     How should the addressbook UI work ?
     These are our options:
     -------

     1. No UI.

     2. A UI that only accepts fields we decide upon. This would have
some tabs
     for entering common data plus a spreadsheet-like tab to edit less
common
     fields. Don is currently working on this.

     3. A UI that is built from a specification and adaptable. This
could be built

     from a KConfig file (Rik has some example code working that
produces a dialog

     identical to Netscape Messenger's). This might be more tricky
though...


4. Do not fix the interface at all, simply declare the entry structure.
Then you
might
have different UI's, like a tabular view, kab's "business card" view,
etc.

     -------
     The UI SHOULD be used from every KDE base application to provide
consistency.

This is not possibly and not useful. At least not if you fix the UI.
Think of the
person
selector on korganizer, the address selection in kmail, ...
Would you like to see a tabular view all the time? Something specialized
would be
great.
The best way is to provide an api to use the common addressbook, and
provide one
default database entry interface.

     The UI MAY be used from every KDE base application but may also be
ignored.
     This way apps get to make their own.

That's it.

     A UI that is adaptable so that an application can ask for the kind
it wants,
     doing something like specifying the fields it wants to be available
to edit.
     -------

     ------- Addressbook backend --------

     Having had a peek at Netscape Messenger, it looked like vCard might
be the
     Way
     To Go. vCard is a powerful format that is well specified in an RFC.

     What (Rik) hadn't banked on was that Netscape would drop vCard for
the next
     version of Communicator. Oops.

And they have good reason for it. vCard is a minimal standard, not
enough to
manage all
personal information on the desktop. If you have a look at kab's
AddressBook::Entry class,
you will find the fields that have been requested by the users over two
years.
I believe this
is the minimal entry object.
What is still missing is to add the missing telephone number fields
(using
telephone type
and number, e.g. cellular - 0172 ...).

     Well, it seems now that a good plan would be to use ldif as the
base
     addressbook format. ldif seems to be a good 'base' format, coming
from LDAP
     and
     intended to be used for both object storage and editing. It is
basically a
     simplified X.500 format.

     Using ldif as the base format allows us to basically store what we
like. It's

     difficult to see where information about value typing is stored.
This
     information is going to be vital to us. We need to know when
something's
     going
     to be a date, and in what format that date will be.

To provide an interface to applications, you need to define the binary
interface
of the entries.
Please be careful not to mix the backend and the API.

     Work done:
     Rik has implemented a VCard 3.0 parser. This can also be used to
create
     VCards.
     Rik has implemented an ldif 1 parser. This can also be used to
create ldif.

     The ldif format is still an internet draft and Netscape Messenger
does not
     create ldif according to the current draft revision (4). Thankfully
the draft

     does not seem to have changed greatly since the implementation used
by
     Netscape
     Messenger.

     There now needs to be a decision made as to how addressbook records
shall be
     stored. There are three strong possibilities.

     1. A binary format readable only by kab.
     Advantages:    Fast, compact.
     Disadvantages: Not human readable. May only be parsed by programs
external to

     kab if kab provides a CORBA interface or a library. Must be encoded
to mail.

kab' s format is not binary. See "
~/.kde/share/apps/kab/addressbook.database".
The
interface class is available in libkab, it is a kind of registry.
I personally think this is only ONE of the future interfaces to
addressbook
entries.

     2. ldif
     Advantages:    Rapidly becoming a standard. Human readable.
Mailable.
     Disadvantages: Not yet a standard. Doesn't seem to have a mechanism
for
     giving
     type information. Slower than binary.

And it is not designed to handle all desktop specific stuff.

     3. vCard
     Advantages:    Fixed, well written, usable specification. Fairly
compact.

To compact.

     Exported by Outlook Express. Mailable. Type information given in
     specification.
     Disadvantages: Need to write a parser for 2.1 as have only done 3.0
and you
     can't get away with using the 3.0 parser (a minor matter). Doesn't
seem to be
     a
     way to provide typing information for 'X-' (extension) fields.
Slower than
     binary.

     It's probably safe to assume we can ignore speed issues. The
parsers for ldif

     and vCard are designed to be 'lazy' - that is, extremely efficient.

     We need more information on ldif to find out how type information
may be
     stored. If it's impossible to store, then we cannot use it as the
standard
     format.

     With vCard we have type information for the basic fields, plus we
can use
     'X-KAB-' fields, which we will know the type information for, as we
made
     them.

     It seems like it might be sensible to go for vCard now. IMO (Rik)
ldif seems
     to
     be crippling and only useful as an intermediate format for talking
to ldap
     servers.

     Some sane advice from someone who actually knows about ldif would
be useful !

     ----------------------------

     Well, that's it. Hope I've made, er, myself clear. Anyone else
reading this
     list ? ;)

OK, now the most interesting part: What are the current design goals for
a new
kab?

This topic has been discussed on LinuxTag in Kaiserslautern, Germany,
between
Markus Wuebben (wuebbe00@marvin.cs.uni-dortmund.de) and me. The main
points are:

   * We have to distinguish between the user interface, the internal API
and the
     database backends (definitly, or you will see no apps that support
it).
   * The library must be stripped by all stuff according to the kab
application
     (this is no problem, since the library will be rewritten).
   * The backend database may not be fixed.
   * The application design may not be fixed.

Now I will try to pant the main ideas (make sure to use a fixed font):


--- ....
                                                                       /
---
LDAPInterface (written by Markus)
                                   -(abstract) DatabaseInterface class
---
KABInterface (written by me)
                                  /
                                 /
       AddressBook::Entry class /
                   | (using)   /
                   |          /            |
       AddressBook class --- /-------------| (Binary Interface to the
applications)
                   |                       | (kab, for example)
                   |                       |
                 GUI for editing an entry--|
                                           |

What has to be discussed is whether the DatabaseInterface class and the
AddressBook::Entry class should be CORBA objects.

This is the way the kab library will mainly go. First steps have been
done by
Markus and me.

What do you say?

Greetings,
--Mirko.

--
Denn der  Mensch  liebt und ehrt den  Menschen,  solange er ihn
nicht zu beurteilen vermag, und die Sehnsucht ist ein Erzeugnis
mangelhafter Erkenntnis. (Thomas Mann)

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