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

List:       kde-pim
Subject:    Re: Some notices
From:       Rik Hemsley <rik () rikkus ! demon ! co ! uk>
Date:       1999-08-22 18:26:24
[Download RAW message or body]

On Sun, 22 Aug 1999, Mirko Sucker wrote:

> Hello there,
> sorry that I was quiet for such a long time. I moved to a new flat, got a new
> internet provider ...
> But now I am back.

Welcome back :)

> The first thing is that I want to have a look at the current code, but could not
> find it at cvs.kde.org. I tried kdepim, kde-pim, pim, but none of these modules
> exist. How is it called?

It's 'pim'. It does exist, because I did a fresh checkout yesterday !
> cat CVS/Root
:pserver:rikkus@zeus.informatik.mu-luebeck.de:/home/kde

I think we're using the same server ;)

You'll want to look in pim/kab2 for the stuff I'm working on now.

> (While being eager to have a look at the code)It would be a good idea to
> merge to entry-structures you and I use. My Entry-class grow over a long time,
> and I am sure it suits for the needs of most people. I will contact you about
> it after seeing what is done by now.

I had started using a different approach where people, places, and communication
points were all separate. This allowed you to create a 'place' once and then
associate many people with that place. You could also create more than one
'comms' object for a person (or a place) and use them for different purposes.

This gave a really nice, clean design. It took me a whole week to figure it out
- it provided for holding information in a very logical structure without
redundancy, and it was also correct for everyone on the planet. No assuming
that everyone lives in a city, etc.

At the request of Don, which I think is actually quite sensible, I've now
changed this so that there are only two data types that may be stored in the
addressbook - 'Entity' and 'Group'. Group is derived from Entity and adds
only a list of members, which are references (keys).

An Entity is basically just a list of 'Field', where field is a name/value
pair.

Now, this design is nice and simple, but I still needed a way to find out what
type of data is stored in a field (for parsing)

To solve these problems, we now store the mime type of each field.
This doesn't waste as much space as you'd expect, as most fields are of
type text/plain (maybe we'll use text/unicode or something later) and
null strings for mime type and subtype signify this default should be used.

> 1. I was thinking about a server, but wanted to build the
> database-independant approach I talked of. It seems to lead to the same
> problems I had before - strange exchange of data between two different kab
> instances running different database interfaces, for example. But in
> general, a server is the best idea.

The server is actually a little different to what you'd think.

You start the server like this: 'kab_server <format> <location>'

The server creates an AddressBook object using the format and location
parameters given. The server doesn't pay any attention to these. This way, the
server is independent of the actual implementation.

In fact, the AddressBook object is also independent of the storage, as it
dynamically loads a plugin to handle the storage format requested, telling the
plugin where to find its data (<location>).

So, the only way you'll get an incompatibility issue is if you change the
way that Entity objects are serialised. I'm going to make the server report
its version number on connect. This should resolve that issue.

You should be able to see now that what is actually stored within an Entity
is now not the responsibility of kab. It's the responsibility of a client. This
means Don's UI. I'm sure the UI will be capable of doing at least the fields
that were specified for kab1, plus many more.

> 2. Dynamic loading. Are the problems with dynamic loading and C++ solved? I
> am not at the bleeding edge, I suppose

Used KDE 2 recently ? Your widget theme is dynamically loaded :)

Mosfet seems to have managed just fine. My version in kab2 works ok on my
system, but I'll have to switch from using plain system calls to the 'lt-'
versions (i.e. libtool's dlopen). This is for later, when it all works ;)

Cheers,
Rik

-- 
KDE - Colour Outside The Lines - http://www.kde.org

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