[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:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2003-12-26 15:26:58
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 26 December 2003 16:14, Tobias Koenig wrote:
> 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)

Really? What about apps running on different machines but sharing their=20
files via NFS? Do you really think you don't need lock files?

> and has a simple query language for searching contacts.

Reinventing SQL? :-)

Regards,
Ingo

[Attachment #5 (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]