[Kde-pim] Setting Akonadi agents' mime types

Volker Krause vkrause at kde.org
Mon Sep 14 08:16:25 BST 2009


On Friday 11 September 2009 12:13:14 David Jarvie wrote:
> On Fri, September 11, 2009 9:43 am, Volker Krause wrote:
> > On Friday 11 September 2009 10:24:24 David Jarvie wrote:
> >> On Fri, September 11, 2009 8:09 am, Volker Krause wrote:
> >> > On Friday 11 September 2009 01:38:40 David Jarvie wrote:
> >> >> Why doesn't the Collection show just a single mime type in
> >> >> AkonadiConsole?
> >> >> - is it necessary to do something else to save the new setting?
> >> >
> >> > I'm wondering why you try to modify the content mimetype from within
> >>
> >> the
> >>
> >> > application at all. Usually it's something only the resource should
> >>
> >> do,
> >>
> >> > as it
> >> > is the only thing that knows what types it can handle. If possible any
> >> > resource-specific knowledge should be avoided in the application, it
> >>
> >> will
> >>
> >> > fail once you exchange the resources at some point.
> >>
> >> It's only when creating a new collection that I want to specify a
> >> particular mime type. After any alarms have been added, the resource
> >> knows
> >> what mime type it is from the alarm type. Or do you think that it would
> >> be
> >> better to define separate resource types?
> >
> > What are those different types anyway? That might help understanding the
> > scenario here :)
>
> They are for active alarms, archived (i.e. expired) alarms, and alarm
> templates. There is no absolute necessity to keep these types in separate
> files, and Akonadi's filtering facilities would help here, but it is more
> satisfactory from the user's point of view for the purposes of backing up,
> etc., and it's also easier when requesting information for debugging
> purposes.

I see. Similar problem as we had with the mail dispatcher agent, it 
required "special" folders as well (e.g. the outbox). This doesn't map nicely 
to Akonadi though, as we can have arbitrary many resources now that have a 
folder named "outbox". Same for the sent-mail folder. 

The current solution there is to create a local maildir resource by default 
and set up the required special folders there, but let the user change them 
to other locations if he wants to. Something similar might work for the 
exired alarm folder in KAlarm.

Besides the content mimetype, there is another way of attaching such metadata 
to collections btw, you can add instances of Akonadi::Attribute subclasses to 
collections (see the API docs of Akonadi::Entity, the base class of 
collections and items for that).

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/20090914/dcc3b862/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/


More information about the kde-pim mailing list