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

> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1365/
> -----------------------------------------------------------
> 
> Review request for KDE PIM.
> 
> 
> Summary
> -------
> 
> This patch adds a ItemSerializerPluginV2 class which contains API for
> merging two items, and for returning which parts are available for a given
> item.
> 
> For 'legacy' serializers which use ItemSerializerPlugin, there is a slower
> method of merging by multiple deserializations. The default implementation
> of merge also uses this slow method.
> 
> I also need to do a dynamic_cast of plugins in the ItemSerializer class so
> that it can know the capabilities of a plugin.
> 
> Both merge, and availableParts are available through the Item class.
> 
> These changes allow the ETM to function properly when a itemChanged signal
> is recieved. Current behaviour is to over-write the item currently in the
> internal data structure with the newly recieved item. The problem is that
> if the new item does not contain parts which the old item did, the old
> parts are discarded. The new behaviour is to merge the parts.
> 
> Additionally, the available parts are made available through the model,
> which means that a model could by default only fetch the Envelope part,
> and fetch the body on click, and fetch an attachment from akonadi when it
> is selected. A PartFetcher class is provided for convenience. Doing this
> operation though a generic, very ugly hack with setData/data allows the
> use of the PartFetcher class through proxy models, and it also allows the
> model to cache parts. That means that if the user clicks several emails
> for example, their body parts are retrieved from Akonadi only once, and
> cached, rather than being fetched multiple times as is the current
> behaviour.
> 

As an addition to this, I think it's time to revisit an old topic about 
standardizing some payload parts.

The current situation is that we have Item::FullPayload which is an alias 
for 'RFC822'. Current serializers and resources don't have a problem with 
this as far as I know. Volker mentioned possibly using something less MIME 
specific for the name, but I'm not sure it's a big deal for the 
EventIncidence serializer to respond to 'RFC822' if it's hidden behind 
'Item::FullPayload' anyway.

I would like to see more use of such standard part names though.

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.

This will allow the data model for an application to be minimal, and only 
request more parts of an item on demand. ETM will probably also get some 
kind of purge/prune api too so that large stuff doesn't stay forever on 
systems which are never turned off.

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.

* Item::FullPayload
As it is now. Everything for the item.

Thoughts?

All the best,

Steve.



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