[Kde-pim] RFC: Akonadi MIME type filtering/matching

[Volker Krause]

Hi,

On Sunday 26 April 2009 21:10:05 Kevin Krammer wrote:
> while investigating why some people didn't see any folders in the new
> storage collection selection dialog the KResource client bridges I
> discovered a that this basically happened because of another use case of
> MIME type filtering.
>
> The use case I had in mind while working on Akonadi::MimeTypeChecker is
> this:
>
> an application wants to get all collections containing any kind of calendar
> data, so it filters collections based on MIME type text/calendar.
> This matches collections with text/calendar and any of its subtypes, e.g.
> application/x-vnd.akonadi.calendar.event
> When filtering for the event subtype, only those remain that explicitly
> include that sub MIME type.
>
> The problem is now that when I want to list all viable storage collections
> for an event, I filter for application/x-vnd.akonadi.calendar.event
> Collections which just specify text/calendar do not match this strict
> subtype filter.
>
> I didn't catch this locally since I had been testing with the ical resource
> and it specifies all sub types explicitly, satisfying both scenarios.
> However, I think it is legitmate for a resource to only specify the common
> type if it can handle all subtypes anyway.
>
> Anyone having suggestions on how
> CollectionFilterProxyMode::addMimeTypeFilter() should really behave?

I though about this a bit and I think the following (theoretical) solution 
satifies both scenarios:

(1) starting from the given type, include all more specialized types, ie. 
include the entire sub-tree (that's what we do now)
(2) include all more generic types that can store the given type, ie. include 
the path from the given type upwards in the mime tree up to a given most 
generic type.

So, in the second use-case listed above (storage collection for an event), (2) 
would also include text/calendar (which we want) but also text/plain or 
application/octet-stream for example. While theoretically correct (both can 
store events as well), it might not be desired in practice. Especially for 
viewing, we do not want to include those, therefore the need for a second 
parameter to specifiy the most generic type we are interested in (here 
text/calendar).

However, considering we do not have very generic types like text/plain etc. in 
Akonadi currently, we could even get away without the second parameter for 
now.

regards
Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090430/3ddef2c0/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/