[Kde-pim] Review Request and [RFC]: Add capability to merge items containing multiple parts, and to know what parts are available for a given item.

[Kevin Ottens]

On Monday 24 August 2009 14:57:48 Stephen Kelly wrote:
> OK, so if the Envelope doesn't have information about whether an email has
> attachments or not, we'll probably need the body structure to determine
> whether to show an attachment emblem or not.

Just checked to be fully sure. That's the case, ENVELOPE is not enough to 
guess attachments, querying BODYSTRUCTURE is needed.

> That means the resource will
> pretty much always be requesting the body from the IMAP server even if the
> akonadi client only requests the Envelope. Would it be possible (and
> standard) to answer the question of whether an email has an attachment
> using only the Envelope?

Nope you apparently can't, looking at the RFCs I don't see how you could 
without BODYSTRUCTURE or without asking for the whole message.

In any case my point was that for really mobile client you maybe should live 
without displaying the attachment emblem in the message list... And then ask 
for the body structure only when the user reads the mail text.

For the fat desktop yes, in the end we'll ask for both envelope and body 
structure all the time.

> I think if it's possible to get enough information from Envelope that we
> don't need BodyStructure in every case, then it's up to what the needs of
> the applications are. If applications have a need for the body structure
> without content, then the serializer could make that available.

Well they have this need, that'd be needed so that KMail can show the message 
structure without downloading the whole mail.

> It doesn't
> have to be a standard partname on Item though. You could create
> MessagePtr::BodyStructure as an alias for "BODYSTRUCTURE" or whatever, and
> just make the serializer return that in its availableParts.

Sorry, I'm not following there. In my opinion it should be standard anyway, so 
that we don't need to special case in apps for messages. Moreover the calendar 
items can have attachments too, then you're probably back to the same kind of 
issues.

> OK, so maybe for an item which you already have the body payload for (the
> text etc) the serializer would say that parts ("RFC822", "attachment_1.1",
> "attachment_2.2.1") are available. Would that be cross resource? I mean if
> the email came from a maildir folder or mbox, would those resources be able
> to handle an attachment 'address' like that? Does MessagePtr know the
> addresses of its attachments?

Yes, as it is handled by KMime, and MessagePtr being a shared_ptr to a 
KMime::Message it's definitely supported. The class providing this feature is 
KMime::ContentIndex.

> Would it make sense or be possible to return
> the content-IDs of the attachments instead in availableParts?

AFAIK, getting the Content-ID would require even more querying after you got 
the BODYSTRUCTURE.

> This discussion is quite separate to the patch as it is now, so I'm going
> to commit a version of the patch with Thomas's comments taken into account.

Sure.

Regards.

PS: I'm now subscribed to this list.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090824/6515eb24/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/