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

List:       kmail-devel
Subject:    Re: [PATCH] make kio_imap use peek and kmail set imap read status
From:       Carsten Burghardt <burghardt () kde ! org>
Date:       2004-01-01 15:42:47
Message-ID: 200401011642.49594.burghardt () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 01 January 2004 15:26, Ingo Klöcker wrote:
> On Tuesday 30 December 2003 20:52, Till Adam wrote:
> > On Tuesday 30 December 2003 18:25, Ingo Klöcker wrote:
> > > About the change in kio_imap. It would be nicer if it would be
> > > possible to use BODY and BODY.PEEK (depending on the situation).
> > > Isn't it possible to extend the IMAP slave accordingly? Then no
> > > apps that rely on the current behavior would break.
> >
> > Hm. I kind of think it is really a bugfix, as the old behavior was
> > arguably more of a nasty side effect than intended behavior. Maybe
> > you are right, though. Carsten, any idea on how you want that done?
> > Do you agree with Ingo?

Yes, the current behaviour should be the default so that apps can use the 
kioslave without changes. But I do agree that your change is a bugfix, can 
you create a patch that uses BODY.PEEK explicitely?

> To be honest IMO the fact that BODY as a side effect sets the /SEEN flag
> is braindead. Maybe this made sense when the IMAP protocol was designed
> (and maybe it still does make sense with simple mail clients like web
> mail frontends or Konqueror used with kio_imap), but with modern mail
> clients this doesn't make that much sense because with modern mail
> clients downloading a message isn't equivalent to the message having
> been read. For example think about prefetching the next few IMAP

Great parts of the imap implementation are braindead (just look at the 
bodystructure) ;-) But this behaviour is normally useful because this way the 
server can maintain the flags easily. 
Nevertheless this change is indeed a bugfix because kmail doesn't behave as 
expected as Till already explained.

> messages while the connection is idle so that switching to the next
> message would be more or less instantaneous. (Wouldn't that be a cool
> feature?)

Not bad ;-)

[Attachment #5 (application/pgp-signature)]

_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel


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