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

List:       kde-pim
Subject:    Re: [Kde-pim] Why does Korganizer not like December 22?
From:       Tobias Koenig <tokoe () kde ! org>
Date:       2003-12-26 15:14:38
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tue, Dec 23, 2003 at 10:46:12AM +0100, Cornelius Schumacher wrote:
> On Tuesday 23 December 2003 09:49, Best, Jan-Pascal van wrote:
Hi,

> All this is already done by the calendar resources. It's not perfect yet, but 
> all the infrastructure is there and is used. The libkcal API provides all 
> what we need.
> 
> The remaining problem is that multiple processes open multiple instances of 
> the Calendar object, so that the calendar data is held in memory multiple 
> times. This could only be solved by providing some kind of daemon holding the 
> data and the libkcal backend forwarding requests to that daemon, e.g. by 
> DCOP. This could be implemented, but I'm afraid it would kill performance as 
> the calendar data is accessed rather heavily by programs like KOrganizer. 
> Data bases aren't designed for interactive real-time editing of data.
Hmm, I'm currently working on a similar test implementation for the
address book code.
We would have a central contact dcopservice which does the whole locking
in an upper layer (no lock file is needed since the server knows which
app uses which contact/resource) and has a simple query language for
searching contacts.
For all standard tasks (editing a contact, searching a couple of
contacts, contact preview) so called components will be provided, which
handle the communication with the dcopservice and shall be easy to
integrate in other applications.
For special task there will be a base component where you can derive
from your own class.

I guess something similar would be possible for libkcal as well.
With a query language there wouldn't be a need for loading the whole
calender at once in every app. Instead KOrganizer could ask the dcop
service for all events which exists for the current week, the current
day or the next three days.

IMHO we should pay more attention to this service/component based
approach since it makes integration a lot easier (and via a dcop/dbus
bridge even non-kde apps could use the data)

Ciao,
Tobias
-- 
Can a government that shoots at reporters be democratic?
Separate politics from religion and economy!

["signature.asc" (application/pgp-signature)]

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

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