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

[Stephen Kelly]

Kevin Ottens wrote:

> On Friday 21 August 2009 13:00:19 Stephen Kelly wrote:
>> You probably don't want to always get the body structure from the server,
>> but just the Envelope. Does the envelope provide information about
>> attachments? It would need some anyway if we're to show a attachment
>> emblem in the list view.
> 
> AFAIK in IMAP that's different things (envelope and body structure). Now
> on the IMAP resource side we can do it like we want. So if the resource is
> requested for an envelope part I can under the hood request both envelope
> and body structure on the resource side.
> 
> We just need to take the decision: do we expose a different part for body
> structure on the Akonadi side?
> 
> Either way is fine with me I think. My only worry would perhaps be: for
> really mobile client and high latency wire, asking for the body structure
> could consume too much (can get a bit large if the structure is really
> complex, which happens if you got signature, html, non html content, and
> attachments). So we might want to decouple them in order to allow mobile
> client to really request the minimum of information if needed.

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?

> 
>> Actually it was intended to retrieve the small ones straight away,
>> because there's no value in starting a separate job for each little
>> attachments. I think the value in getting attachments separately is for
>> big attachments.
> 
> I'd advocate about the mobile use case again, see above. A few megabytes
> can make a whole lot of difference on your phone bill. :-)

Agreed.

> 
>> Is Item::BodyStructure useful outside of the resource? I mean would an
>> application ever want to fetch it? Given Item::availableParts, I don't
>> think it's needed.
> 
> You're right, I overlooked the Item::availableParts in your patch. That
> said the question stays open: do we allow to request it separately or not?
> or to inhibit its fetching? (thinking mobile again).

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.

Kevin Ottens wrote:
> On Friday 21 August 2009 14:56:31 Volker Krause wrote:
> > On Friday 21 August 2009 13:00:19 Stephen Kelly wrote:
> > > I would imagine the serializer could translate 2.2.1 into "funny
> > > cats.mpeg". I don't think applications should have to deal with
> > > "2.2.1".
> >
> > I don't think that's a good idea. The only way to uniquely adress an 
> > MIME attachment is the above notation. That's what eg. 
> > Mime::ContentIndex does as well. Using attachment names will break 
> > sooner or later.
>
> Agreed. First case of breakage: two attachments with the same name. That's 
> that easy.

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?

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.

All the best,

Steve.


> 
> Regards.



_______________________________________________
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/