[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:       "Best, Jan-Pascal van" <j.p.vanbest () tbm ! tudelft ! nl>
Date:       2003-12-23 8:49:54
[Download RAW message or body]

> 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?").

Doing this properly could be a rather hard problem, I'm afraid...

Jan-Pascal


_______________________________________________
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]