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

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

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

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.

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