[Kde-pim] Re: How Resources and Collections play together

[Christian Mollekopf]

On Friday 14 January 2011 14:37:34 Thomas McGuire wrote:
> Hi,
> 
> let me try to answer some questions I know about, others can fill in the
> blanks.
> 
> On Friday 14 January 2011 13:04:07 Christian Mollekopf wrote:
> > I'm a bit confused how akonadi resources and collections play together
> > exactly.
> > 
> > As far as I understand it, a collection is the akonadi internal
> > container. While the collection doesn't need a resource to exist, a
> > resource is needed to make the link to the storage backend (filesystem,
> > google, etc.).
> > 
> > So if i want a new calendar I create a new calendar resource (not a
> > collection), which will in turn generate a new collection, associated
> > with the resource.
> 
> Yep.
> 
> > So I assume normally there is 1 resource with 1 associated collection,
> > but there can be special resources which have several collections.
> 
> Yes, correct. Quite a lot of resources have multiple collections.
> 
> > What I need to know:
> > 
> > Is the resource responsible for creating/deleting the collections?
> 
> Yes, the collections need to be created in
> ResourceBase::retrieveCollections()
> 
> > So as an application developer, do I always work with resources not
> > collections (speaking of creating/deleting toplevel
> > collections(respectively storage locations))?
> 
> Not sure what you mean here. The API for applications can deal with
> collections and resources. Applications in general deal with collections
> more than with resources.

I was talking of the situation where I ask the user "where do you want to 
store your todos?". I think it is clear now that I have to create a new 
resource in this case, and not a new collection belonging to an existing 
resource.

> 
> > If I want to make a dialog where the user can choose, where to store his
> > calendar files, is it ok to display a list of collections with the
> > mimetype which i need? Or should I somehow list the resources?
> 
> Listing the collections should be enough. There is
> Akonadi::CollectionDialog and Akonadi::CollectionComboBox for this
> already, btw.
> 
> > In the ChangeRecorder for the EntityTreemodel, should I rather watch the
> > collections or the resources? Whats the difference?
> 
> No idea.
> 
> > Can Collections contain items without a resource associated?
> 
> No. Each collection belongs to a resource, and as soon as you put an item
> in it the item will belong to the resource as well. When that happens,
> ResourceBase::itemAdded() is called, and the resource is responsible for
> storing the item in the backend storage (filesystem, server etc). Akonadi
> might later ask the resource for the item again, in
> ResourceBase::retrieveItem(), in which case the resource needs to read the
> item from the storage backend and pass it on the Akonadi.
> 
> > If I want to have a trash collections for items of various mimetypes, can
> > I create a collection directly from my app, without a resource? I just
> > want to keep the items there for a couple of days and then delete them.
> 
> You can create a collection directly from your app, but a collection always
> belongs to a resource. For example the trash collection in KMail is owned
> by the maildir resource, and some IMAP resources also have trash
> collections.
> 
> > Would it make sense to create a trash resource, which accepts all kinds
> > of mimetypes, and deletes the items after a configured time, or is that
> > not the purpose of resources?
> 
> I would somehow prefer having a trash collection in each resource where it
> is needed (maildir, IMAP etc). 
> No idea though how that would work with
> ical resources, which only have a single collection right now. Maybe a
> trash resource here would make sense.
> 

I also thought about that since the resource needs to know how to store the 
given item, so it would make sense to keep the same items together.

The problem I see, is with resources that don't support collections. I want to 
store for instance events in a google-calendar resource, which (I assume) does 
not support multiple collections (i guess that is also what you meant with the 
ical resource).

So I see three options:

-we implement collection support in all resources where we want a trash

-we create a trashresource (which is really only a normal resource with a 
local storage format) for each resource which needs a trashbin. The resource 
is automatically created by Akonadi::Specialcollections in i.e. 
~/.local/shared/akonadi/trash/

-we create a special trashresource which can handle all needed datatypes 
(maybe we could use the normal resources as backend for the different datatypes 
by adding some api to the resources). This trash resource could also take care 
of deleting the files after a configured time (or is that a job which should be 
handled by the application?).


Option 1 doesn't seem easily feasible.

Option 2 seems to be the easiest to implement, but doesn't allow the resource 
to automatically cleanup the trash.

Option 3 is therefore my candidate

On the other hand I wouldn't know how to integrate that approach with the 
maildir trash approach, where another resource is not an option since the 
content of the whole resource (including trash) must be synced to another 
server. I guess it should be up to the application to decide what is used.

What i would propose:

A new class Akonadi::SpecialTrashCollection which will create a new 
TrashResource with the mimeType of the resource for each resource.

The TrashResource itself is just a wrapper for a normal resource, which has a 
local storage format, and additionally can be configured to automatically 
delete old items.

So i.e. I request a trash collection for an google-calendar resource:
The mimetype would be "text/calendar", so if there isn't already a 
TrashResource for the given google-calendar resource, a new 
TrashResource("text/calendar") would be created. Internally this would create 
an ical resource (or another resource which can handle "text/calendar"). The 
collection of this ical resource would then be returned as trash collection.

Akonadi::SpecialMailCollections is not touched, and will continue to work as 
it is.

Thanks to all of you for sheding some light on the topic =)

Cheers,

Chris

> In general, this should be handled by the Akonadi::SpecialCollections
> mechanism. The apps ask this class for a specific collection, e.g. when
> KMail needs a trash it asks
> Akonadi::SpecialMailCollections::collection(Akonadi::SpecialMailCollections
> ::Trash).
> 
> Regards,
> Thomas
_______________________________________________
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/