[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:       Eugene Nine <enine () ninefamily ! com>
Date:       2003-12-26 11:10:12
[Download RAW message or body]

On Friday 26 December 2003 03:14 pm, 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) 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
As far as performance is concerned, wouldn't having the backend service like 
that be a bit slower for small files, but the performance compared to large 
files would be better.  Say for example it takes .01s to load and save a 
small ical file and .05s to access it via a dcop server, the dcop server 
method is slower.  Now take a packrat like myself with a huge ical file that 
takes 1s to load completely (longer than that actually), I would have a 1s 
delay the first time the file is opened which should happen at logon is I 
have the Korg arlam dameon running in the tray so each time I open and close 
korganizer or edit an entry after that I would only see the .05s delay.  Then 
in the background the dcop server would save the file at regular intervals, 
or if you wanted to get really fancy create a transaction log to allow roll 
back and forward of changes in the event of an oops or crash.
_______________________________________________
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]