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

List:       kmail-devel
Subject:    Re: PATCH: sanity checking
From:       Stefan Taferner <taferner () kde ! org>
Date:       2001-07-20 7:22:53
[Download RAW message or body]

On Friday, 20. July 2001 00:04, Don Sanders wrote:
> On Thursday 19 July 2001 09:09, Stefan Taferner wrote:
> > On Tuesday, 17. July 2001 12:51, Don Sanders wrote:
> > > On Tuesday 17 July 2001 10:11, Stefan Taferner wrote:
> >
> > Maybe I do not get the point, but last time I looked at
> > the code (some weeks ago) there was code for various
> > locking forms.
>
> That's for the local account eg /var/spool/mail. For that
> locking is very important.

Ok.

> > I am tempted to say "make it configurable", but this
> > might not solve the problem well.
> >
> > How about some detection code that tests if locking is
> > possible? I am thinking about putting an alarm signal on
> > guard to stop the locking attempt after, say, 2 seconds?
> > If locking fails kmail could use something else.
>
> I would rather discourage users from using an external
> program to modify files in ~/Mail.

;-B

But nevertheless it would not be hard to try if locking is
possible and stop trying if it is not. This would only be
necessary when kmail starts up.

> If you are away on hoilday and want to ssh in and use pine
> or something then fine.  But in general it's a bad idea
> because after an external program modifies a file in ~/Mail
> KMail then has to synchronize its index files with modified
> folder files.
>
> Basically there's no reliable way of doing this efficiently
> (because mail can be deleted as well as appended to folder
> files).

It could probably be done somehow. E.g. by shamelessly
modifying the "From " line that separates two messages
and adding a somewhat unique id there. Then an alogrithm
could find all the original messages if the folder was modified
(in hope that the "From " line was not modified too ;-)

> Mail clients like pine and mutt that support external apps
> modifying ~/Mail files suffer from severe scalability
> problems. They can handle say 5k messages ok but they are
> unusable once you have 50k messages in a folder. KMail can
> handle 50k messages in a folder ok now (well next/prev
> unread message can be appallingly slow in KMail but that's
> a small fixable problem).

Yep, that's a pity.

> > Doesn't a modal dialog block the program? Then kmail
> > could terminate afterwards.
>
> Not completely. Timers still seem to fire for instance.
> Somehow showing a kdialog caused people to lose mail so
> I've been very cautious since then.

Ok.

Hehe, reminds me on the time when I thought that I can use
alarm() to program a nice animated busy pointer.... ;-)

--Stefan
_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

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