Re: IMAP and meeting invitations

Heiko Hund <[email protected]>
Newsgroups gmane.comp.kde.devel.kmail
Message-ID <[email protected]>
Hi again,

On Thursday 17 May 2007 21:33:32 Ingo Klöcker wrote:
> On Thursday 17 May 2007 20:32, Heiko Hund wrote:
> > Is there a way to force fetching/display of text/calendar mime parts?
> > I was thinking about developing a patch that adds an exception for
> > meeting invitations. Any ideas where to look to get started?
>
> In BodyVisitor::BodyVisitor() in bodyvisitor.cpp a list of mime-types
> that should always be loaded is created. I guess the mime-type used for
> invitations should be added to it.

thanks for the pointer. Attached a one liner that fixes the problem. I'm not 
sure if there are other situations where "text/calendar" mime parts come in 
and should not be loaded. They are never much bigger than the invitations I 
suppose, so this might not really be a problem. Anyone more knowledgeable 
than me wanting to comment on this? If there are no concerns, I'd love to see 
this committed.

> This class is used in ImapAccountBase::handleBodyStructure() to
> determine the body parts that should be loaded. The only fallback from
> load-on-demand to load-everything I can see there is if "more than 50%
> of the parts have to be loaded". I can't see any indication of a
> threshold for the message size (but maybe I looked at the wrong spot).

Well, both invitations I was talking about had three mime 
parts: "text/plain", "text/html" and "text/calendar". So that can't be the 
reason for the different loading strategies. I'll take a closer look to see 
if all of the working invitations had a size less than ~5k when I get back to 
work.

Regards
Heiko

_______________________________________________
KMail developers mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kmail-devel
meeting_invitation.patch.gz (application/x-gzip, 229 B) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.