[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:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2003-12-23 9:46:12
[Download RAW message or body]

On Tuesday 23 December 2003 09:49, Best, Jan-Pascal van wrote:
> > Any idea how to make this as efficient as direct function
> > calls? At the moment
> > the calendar is just a normal C++ object which is present in
> > memory and all
> > the data is passed through the regular C++ API. To replace
> > this by DCOP would
> > mean a DCOP call for each and every little piece of data
> > which is shown on
> > the screen or processed in any way. This would be quite some
> > overhead because
> > all the data has to be serialized/deserialized and it
> > wouldn't be possible
> > anymore to pass pointers to objects in memory.
>
> Is it a possibility to have the resources arrange this? File-based
> resources could use a lock file (which could, by the way, also work
> between separate KDE sessions, possibly on different machines, using
> the same calendar file); some server-based resources wouldn't have to
> do anything at all, or maybe regularly poll the server for updates
> (I'm working on this for the Exchange resource).
>
> Now that I'm thinking about it, file-based resource would also need to
> do something like polling, so that changes in the disk file by another
> process are reflected in the GUI. And what should be the behaviour
> for concurrent editing? I would say a warning if you click OK
> in the second edit ("This event has been changed by another program.
> What would you like to do? Overwrite those changes, cancel local changes,
> or duplicate this event?").

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.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
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]