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

List:       kmail-devel
Subject:    Re: ClientInterface
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2003-07-20 12:38:56
[Download RAW message or body]

On Saturday 19 July 2003 15:09, don@sanders.org wrote:
> > Strangely enough sendmail, procmail and several running
> > mutts don't have a problem with concurrently accessing
> > /var/spool/mail/user.
>
> Yes they do have a problem, or mutt has a problem. It relies on a
> ancient non-scalable method or reading entire mail boxes.
>
> KMail, Netscape Mail, Mozilla Mail, Evolution, Sylpheed, Outlook,
> Outlook express, any sane mail client developed in the last 5 years
> uses index/summary files to handle large amounts of mail efficiently.
>
> I certainly don't want to devolve back to a mutt like way of reading
> in entire mbox files, that would suck.

Of course, it would suck. But this would only be necessary in case 
another program touched the mbox files. People who want to use mutt and 
KMail will be able to live with this. OTOH, we could simply tell 
everyone to use maildir if they want to use mutt and KMail. This will 
be much easier than resyncing the index with mbox files.

> > > If KAddressBook is showing the results of a search and
> > > being used to delete messages, and KMail is checking mail
> > > then how are you intending to have these different processes
> > > modify the .index files at nearly the same time? How will the
> > > integrity of KMFolder objects be preserved in KMail when the
> > > KAddressBook process is modifying the
> >
> > .> index files for that KMFolder?
> >
> > > Please provide a link to example software that solves this
> > >problem, or outline a sketch of how you intend to solve it.
> >
> > See above. It's as easy as
> >  do {
> >   while ( exists .foldername.lock.* ) wait;
> >    if ( timeout ) return TIMEOUT;
> >    touch .foldername.lock.hostname.PID
> >   // avoid race condition
> >    if ( .foldername.lock.* != .foldername.lock.hostname.PID ) {
> >     unlink .foldername.lock.hostname.PID
> >      wait random amount of time
> >   }
> >  } until ( exists .foldername.lock.hostname.PID )
> >  do operation on folder
> >  unlink .foldername.lock.hostname.PID
>
> You still haven't understood the problem.
>
> The KMail process has a KMFolder object in memory which is a
> representation of the index file. If the KAddressBook process has
> modified the index file (or a dependency) then the KMail KMFolder
> object is now invalid and needs to be regenerated completely, that's
> inefficient, unsafe and that's the problem.

Yes, it's inefficient. But this will only affect people who want to use 
mutt and KMail or several KMails. I don't see how this is unsafe. We 
already do this with online IMAP. I don't see any problem here.

Regards,
Ingo

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]