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

[Ingo Klöcker]

On Friday 21 August 2009, Stephen Kelly wrote:
> Kevin wrote:
> > On Thursday 20 August 2009 15:32:55 Stephen Kelly wrote:
> >> We have several common use cases for most item types:
> >>
> >> * Show in a list. Requires only a minimum amount of information.
> >> In any message types, this is just the Envelope presumably.
> >> * Select. 'Read email' type use-case. Requires that the entire
> >> body is available. I think this is 'Body' part in mail serializer.
> >> * Attachments. 'Download/read attachment' type usecases. Get the
> >> attachment named 'funnycats.mpeg' or 'TPS reports.pdf'. I know at
> >> least events can have attachments, so the kcal_serializer should
> >> presumably have some way of handling this kind of behaviour.
> >
> > I think that summarizes pretty well the use cases. There's probably
> > a catch though, and your mail isn't clear about that. To cover the
> > attachments case, to know that I want "funnycats.mpeg" I need to
> > know it exists in the first place. So either "Body" provide it, or
> > you need an extra part for that.
>
> Right. That's what Item::availableParts is for in the patch. The idea
> is that the serializer learns the availableParts by looking at the
> body structure I guess.
>
> I think that means that mail resources have to always retrieve at
> least the body structure from the server so that the serializer can
> know what attachments/parts are available.

Yes.


> For other types, the situation may be similar.
>
> 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.

No. The envelope only provides information about (some of) the top-level 
headers of the message. If you want to know if a message has 
attachments then you have to fetch the body structure.


Regards,
Ingo
-------------- 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/20090821/ec13253b/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/