Mike Pilone wrote:
> 
> Hello All,
> 
> I was recently talking with Greg Stern (of abbrowser conduit fame) about the
> state of KDE PIM. In our discussions, we started to through around some ideas
> of redesigning the entire KDE PIM API.

Mike Pilone wrote:
> 
> Hello All,
> 
> I was recently talking with Greg Stern (of abbrowser conduit fame) about the
> state of KDE PIM. In our discussions, we started to through around some ideas
> of redesigning the entire KDE PIM API.

Hi guys,

first, let me clarify some points regarding the intentions and the
history of the KDE PIM code I contributed so far.

I am very happy to see Mikes efforts and his draft of a new PIM API
design. I agree that a lot has to be done.

When I started to write kab, XML was just invented, and korganizer was
not ready to be included into the KDE distribution. kab was added to
kdeutils shortly after the release of KDE 1.0. A few days before KDE
1.1, Preston, the former korganizer developer, asked me to provide
access to the addressbook. Since there was very limited time left, we
decided to just split the kab application
sources in a part to access the database file and the user interface.
That is how libkab was born. We knew its approach was limited and weak,
but it worked out for the time being.

After the release of KDE 1.1 I refurbished the API and the data
structures stored according to a lot of user requests, but the basic
idea behind it stayed the same.

Again shortly before the release of KDE 2, Rik proposed a new approach
for an API using more advanced technology and ideas. Since I agreed that
the approach was more powerful, I declared the KABAPI to be finished.
>From that point, the only thing done to it was fixing of bugs. This is
the reason why the API was not adapted to powerful techniques like DCOP.

Since the new API has not been finished, this is also the current status
of the KABAPI: it is - as far as I know - free of bugs in its limited
functionality, but has not evolved along with the other KDE
technologies.

So far for history. Now for a few comments on Mike's draft.

There are some points or experiences from the KABAPI that should be
taken into concern when designing a new one:

   The API was designed to be extendable without breaking downwards
   compatibility (this is a point Mike pointed out, too). To achieve
this,
   it used a structured text-based data file with some similarity to
XML.
   There is only one limitation in that approach - the size of the
contents
   of the data fields in the records is usually not limited. This make
   using real table-based databases rather complicated.
   Lessons learned: Use an extendable data structure. 
                    Ensure backward compatibility. 
                    Limit record and field sizes appropriatly.

   Users expect their PIM data to be useable independantly. KAB did not 
   provide a way to mark an entry exported somewhere else for a later
   update in the database.
   Lessons learned: Give all records a unique key so that it is
                    distinguishable from other records in the same or
                    other databases.

   The following topics are the features requested by kab users most
often
   in replies to me:
   - the possibility to order entries in a hierarchy
     (not just groups), to be able to follow, for example, a corporate
     structure
   - the possibility to assign entries to categories
   - the possibility to share the whole or parts of
     the database with others
   - simplicity
   - security
   Lessons learned: Give the records a hierarchy.
                    Implement categories. 
                    Let the API be accessable from within a KDE session
(not
                    requiring any assistance from a database or an
                    internet connection), but also work for groups of
people. 
                    Keep it simple.
                    Implement strong encryption features etc to ensure
no 
                    personal information is spread to others EVEN ON
                    NETWORKED SERVERS.


To Mike's draft, I would like to add one more thing (see his drawing on
the web page):

The new API should be partened into one half that is supposed to run
inside
a KDE session (like most applications), and the other part that might on
the same host or on another, independant system (basicly the right half
of
the new PIM API). This would allow to access the PIM data either in work
groups or via the internet from another place.

This are my points so far. I was working on a server design to
interconnect
KDE sessions. This might be one of the starting points for the new
system.

Byebye,
--Mirko.
-- 
I am wrong.
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<