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

List:       kde-pim
Subject:    Re: [Kde-pim] A Daemon Alternative
From:       Reinhold Kainhofer <reinhold () kainhofer ! com>
Date:       2005-10-14 15:15:29
Message-ID: 200510141715.33375.reinhold () kainhofer ! com
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Freitag, 14. Oktober 2005 15:09 schrieb Mark Bucciarelli:
> On Fri, Oct 14, 2005 at 10:33:07AM +0200, Reinhold Kainhofer wrote:
> > And without a daemon, each instance of the resource would have to parse
> > the entire .ics file to rebuild the index...
>
> No.
>
> List directory-->any new/missing files names?  If yes, load that new
> file name.
>
> You only need to reload changed events to rebuild the index.  This will
> be very fast.

Same with a daemon, only that the file still needs to reload the changed 
events once as opposed to multiple times when each instance reloads. 

Your arguments are for the  file resource vs. dir resource issue, where it's 
clear that the dir resource is better performance-wise and conflict-wise. 
Using a dir resource as opposed to a file resource and using a daemon are not 
mutually exclusive!



> > The application would only have a copy if it's really working on that
> > event/journal/todo/contact/whatever.
>
> Open korg, view this month-->korg has a copy of all events this month.

It needs to have a copy of all events of this month and the next three anyway 
if you show four date pickers...


> Move to next month-->korg now has a coyp of this month + next month's
> events.

Why this month's events?

> Choose year view-->korg now has a copy of all events that year.
>
> Right?

Right. Where's the problem? KOrgac still would have only the next few events 
in memory, so together they have
- -) all events (or a proper index, whatever we find more suitable) in the 
daemon
- -) this years events in korganizer
- -) just the next few in korgac
=======================
In sum: Less than twice all events

With each application separately:
- -) The index (~50-75% of the memory of the full data), plus this year's events 
in korganizer
- -) korgac: The Index (~50-75% of the memory of the full data), plus the next 
few events
=================================
In sum: index twice (~100-150% of the memory of the full data), plus this 
year's events, plus the next few. Together this is about the same amount if 
not more of the daemon case.


> - if a event property has a few distinct values, (b/c of how I
>   understand QString to work) these property would consume very little
>   additional memory as the data set scales.  

Only if you copy the string. If you create a new QString, it will occupy the 
usual amount of memory.


>   These types of attributes 
>   are "cheap" to index.

That's only the case for categories.


> - indexing recurring events is tricky and will need some thought.
>
> - it is totally reasonable to restrict what fields people can filter on.

Yes, plus you need to index on what applications need. For events/todos that 
is:
- -) all data required to determine if an event occurs on a given day/in a given 
period -> start, end or duration, due date, all recurrence information 
(expanded if possible to speed up the lookup)
- -) Categories
- -) Parent/child relationships (by UID, which is a string)
- -) priority
- -) summary
- -) finished / percent completed, completion date if applicable
- -) organizer and attendees (in particular, todos assigned to me, to others, 
and organized by me)
- -) alarm trigger times (for korgac, which requests events by time of alarm)
- -) free/busy transparency so the free/busy view knows which events to load to 
determine the busy times
- -) Public/Private/Confidential information, because we need to introduce a 
setting not to show private and/or confidential events


> I wasn't arguing that this case should not be handled.  A solid
> kdirresource + kdirwatcher can handle this.

That's not enough as the current situation clearly shows. What we are really 
missing is a good conflict resolution strategy. And our current reload 
strategy simply leads to data loss all over the place and to crashes that 
cannot worked around or only with a huge effort which we can't afford.



> I was suggesting the case where multiple users accessing a shared file
> resource is a more interesting and important one, and one a deamon
> cannot address.

Why? Your reloading strategy will need to part of a directory resource anyway 
(it actually already is). 


> > Also, how about syncing? This is exactly the situtation where we
> > currently have crashes due to the automatic reloading (when a file
> > changes on disk) that cannot be easily worked around.
>
> You mean this issue?

Yes, and no. The mail is about the situation in korganizer, which is not so 
much of a problem. In kpilot it's worse.
In kpilot the problem is that you need to sync a list of event on the PC with 
a list of events on the other side (handheld, other PC, phone, whatever). 
Once the syncing algorithm has started, the list of events on the PC 
shouldn't be changed in any case (you can't sync to a moving target!), so you 
can't really reload the data, otherwise data loss will occur...

So, while the syncing is in progress (which happens through a chain of method 
calls triggered by singleShot timers), you need to assume that the list of 
events is not reloaded. currently, however, the resource simply reloads 
(either only the changed events for the directory resource or the imap 
resource, or all events for the local or remote file resource) and 
invalidates all existing events in the background. Thus the syncing 
algorithm, which depends on a non-changing list, will crash sooner or later.

> But which do you think it is--a timing issue between signals or a lack
> of a signal?  If the former, then either approach will have the same
> problem.

In KOrganizer, it's the former. In kpilot it is a more fundamental problem. 

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer maintainer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDT8uVTqjEwhXvPN0RAozJAKCHhPDhxKcnvkt+to+oWW+nhIn+xACggzaw
3y1XcrSG+7B6wgewQwyKxf0=
=/GHB
-----END PGP SIGNATURE-----
_______________________________________________
kde-pim mailing list
kde-pim@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]