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

Stephen Kelly wrote:

> Kevin Ervin isn't on this mailing list yet, so I forwarded this mail on to
> him.
> 
> I'm sending his reply in to not break threading.
> 
> Kevin::
> 
> On Thursday 20 August 2009 15:32:55 you wrote:
>> Stephen Kelly wrote:
>> > -----------------------------------------------------------
>> > This is an automatically generated e-mail. To reply, visit:
>> > http://reviewboard.kde.org/r/1365/
>> > -----------------------------------------------------------
> 
> Took a quick look at the patch, even though I won't be the one giving it
> the go, it looks nice. Careful though there's a couple of places where you
> forgot
> spaces between parenthesis, ie (foo) instead of ( foo ).

OK, I'll fix that before committing.

> 
>> As an addition to this, I think it's time to revisit an old topic about
>> standardizing some payload parts.
> 
> Yes! Yes!
> 
>> 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.

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.

> 
> In the case of IMAP it's actually separated, you can get the envelope, the
> body or the body structure. And of course the content of a given sub part.
> 
>> So, I think it would be an idea to standardize some more payload names
>>
>> * Item::Generic
>> Give at least mimetype, remoteId, id etc. No type specific stuff. I'm not
>> sure if there's a use-case for this one. If there isn't, leave it out.
>>
>> * Item::MinimalPayload
>> mail_serializer returns what it currently returns as 'Envelope'.
>> Maintainers of other serializers get do decide and document what
>> information is suitable for that type. For example, for contacts you
>> might return all standard text fields and a photo thumbnail, but no
>> custom fields, and not the unscaled photo.
>>
>> * Item::BodyPayload
>> The bits that are needed to read the email ('Body') and attachments
> smaller
>> than N Mb. Probably all of the contact data including big photo. All
>> event info etc, and attachments smaller than N Mb.
> 
> Well, I'd say the BodyPayload gives only the body, and the body structure.
> The
> whole "attachments smaller than N Mb" looks artificial to me, and meant to
> avoid the difficulty of "addressing a given part". 

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.

We could say that it should get available attachments up to a size of N mb, 
but that has similar problems. So for the moment, we can just leave out the 
small attachments bits. Especially as 'small' has different meaning on 
different devices.

> Unfortunately I think
> we'll
> have to cope with this difficulty otherwise the code in the resources will
> be
> error prone.
> 
> For instance if I have several small attachments in a mail all under the N
> Mb,
> should I download them all? Could be big in the end, and have a slow
> link... and the user might not even want to access any of them.
> 
> So I'd say we should have:
>  * Item::BodyPayload which returns the body + the body structure
> or
>  * Item::BodyPayload which returns the body only
>  * Item::BodyStructure which returns the body structure

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.

> 
> In both cases though, we need a way to ask for a given part of the item
> given
> it's body structure. In IMAP it is done using a pointed notation to
> traverse the tree. For instance 2.2.1, gives me the first sub-sub-part of
> the second sub-part of the second-part of the mail.

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

Thanks for the feedback,

Steve.

> 
>> * Item::FullPayload
>> As it is now. Everything for the item.
>>
>> Thoughts?
> 
> I hope that helps.
> 
> 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/

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