[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.

[Thomas McGuire]

Hi,

On Monday 24 August 2009 14:57:48 you 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. 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?

> 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. 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.

If we have the body structure, it makes sense to return that in availableParts 
as a special partname, yes. The serializer can already create a full KMime 
object out of that information, just that the actual content is empty. This 
probably needs modifications in KMime so that we can differ between empty and 
not-yet-loaded contents.
Once the application has such a KMime::Message with the complete structure but 
not yet loaded contents, it could use the part fetcher to fetch the missing 
contents on demand.

> 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? Would it make sense or be possible to return
> the content-IDs of the attachments instead in availableParts?

I wouldn't name them "attachment", because that is not strictly true, for 
example for HTML messages or signed messages. Just PART_1.1 or so would be 
better.
And yes, that would be cross-resource, since the body structure of the mail is 
the same in all resources, since that maps 1:1 to KMime::ContentIndex. So 
MessagePtr knows the addresses of the attachments, as that information can be 
retrieved by the index() function of its various Contents.
Using the content-id (not the same as content index!) makes no sense, since 
not every MIME part has content ids.

Regards,
Thomas
-------------- 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/014a6724/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/