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

List:       kde-pim
Subject:    Re: Addressbook
From:       Rik Hemsley <rik () rikkus ! demon ! co ! uk>
Date:       1999-07-04 0:26:55
[Download RAW message or body]


On 04-Jul-99 Don Sanders wrote:
> [...]
> That means that it is no longer an address book but a database (or perhaps
> infobase would be a better term).

This is what the 'grand rikkus plan' for kde-pim is :)
The 'infobase' will be comprised of the various apps - kmail will provide the
mail storage and searching, korganiser will provide the todo list. Each will
provide services via CORBA.

Doing it this way, you can make kfind a generic find utility that searches
everything. Select 'emails + todo' and search for 'Don'.

I think this makes for a nicely integrated system and lets the user think
straight. Want to find something ? KFind. :)

It's not a pipe dream either !

> In a sense I guess a pim can be though of as just an application that just
> supports different views of a database. I suspect MS outlook is implemented
> like this.

Yes. Though 'a pim' here is a suite of applications providing services and the
'application' is KDE. Instead of putting everything in one application, we can
split it into several. Of course, there's nothing to stop you making a mega-app
which incorporates everything.

> Note: I don't want to use kab to store e-mail messages but I would like to
> have a view that enables me to search my entire 'infobase' and see a list 
> containing headers for all types of information stored in all known
> infobases. [...]

Yup. That's the kfind-talks-to-some-servers plan.

> 1) I wonder how similar this is to the problems  LDAP addresses. Actually it
> would be pretty cool if the pim could provide views of infobases (not really
> sure if that's the right word) accessed via a LDAP server. LDAP looks
> interesting. (Note I'm just saying this would be cool and we shouldn't do
> anything to make this very difficult in the future but I have no intention of
> doing the work to make this a reality at the moment)

Me neither. I've read through the various LDAP RFCs now and I'm not about to
start implementing any of that. It's certainly something to have at the back of
our minds though - there are plenty of LDAP-interfacing projects going on.
OpenLDAP looks like it may be useful to us. The license appears to allow us to
use code too.

> 2) Similarly it would be cool if the pim was flexible enough to allow views
> of
> KATABASE data. It seems that there is opportunity for us to collaborate with
> the katabase folks, but there is also the danger of duplication of effort. I
> hope that someone from katabase is aware of what we are doing here.

I don't think we'll be duplicating anything for a while yet. When it comes to
the stage where we're thinking hard about locking of records accessed by
multiple users and extremely fast access + searching then it's likely the plan
could be to start putting things like kab into a Katabase type thing. Well, we
should be thinking about this from the start but you get the idea - we need to
be able to read + write ldif + vCard to a file before we worry about a zillion
of them ;)

> Internally I'm using a QDict of (type/value) pairs I think this makes sense.
> We'll talk about this again after I e-mail you my code, yes?

Ok.

> Unless the string is a canoncial representation of the value, I mean I'll try
> parse text entered and reformat it into the correct form. Hmm, I would like
> to
> accept garbage values but somehow signify the fact that they weren't stored
> in
> preferred format.

I think we can come up with some way of specifying the type of an object that's
not one of the 'standard set' - i.e. make it possible to make a
'X-My-Other-Birthday' and specify it's a date. Not too hard.
 
> Okay, I see. I take it that DateValue is just psuedo code right? Is there
> such a type? (I know of QDate)

No, DateValue is an object representing a 'date-value' as specified in the
vCard RFC. It's real, and that code works :) 

>> Perhaps this is a job for the group thing ?
>> assistant.TEL:02838 32844
> Hmm, not sure. As long as the saved file is a valid vCard it should be okay.

That's valid.
content-line: [group "."] name *(";" param) : value CRLF

>> I think you should see that with this kind of system we get to choose
>> exactly
>> what goes on the dialogs and where.
> Yes I agree, it is a matter of priorities.

I can't help it. I'm just hooked on generating everything I possibly can, rather
than hand-coding. Look at pim/vCard to see what I mean - the files are almost
completely autogenerated by some awk. I just fill in a couple of methods.

The idea was to make a little code to read some KConfig and leave the rest of
the dialog to be created at run-time. I'll see what you've done first though.

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]