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

List:       kde-pim
Subject:    - Project Status report -
From:       Rik Hemsley <rik () rikkus ! demon ! co ! uk>
Date:       1999-07-06 12:45:55
[Download RAW message or body]

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).

We're missing some kind of web page that states the goals of the project. This
will be handy to express what we're doing. A basic FAQ is probably the best
plan. Rik has already created some stuff that will be shaped up and put in
place soon.

We haven't yet contacted all the people who may be interested in this project
directly. Rik intends to spam all potential victims with an advert RSN.

The last few weeks have been spent discussing the addressbook, a vital
component of the system.

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.

-------- Addressbook UI ------------
It looks like we're pretty much agreed that the kab UI is pants and should be
replaced in some way.
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...

-------
The UI SHOULD be used from every KDE base application to provide consistency.
The UI MAY be used from every KDE base application but may also be ignored.
This way apps get to make their own.
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.

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.

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.

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.

3. vCard
Advantages:    Fixed, well written, usable specification. Fairly 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 ? ;)

Cheers,
Rik



--
KDE - Colour outside the lines  : http://www.kde.org
[[without]] - software for KDE  : http://without.netpedia.net

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