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

[Christian Mollekopf]

On Friday 14 January 2011 17:18:52 Stephen Kelly wrote:
> Christian Mollekopf wrote:
> > 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
> 
> Option 4 is to mark the deleted items with a flag or attribute and leave
> them in place, and then have a Janitor agent delete them after the
> configured time. I'm not saying that's a better solution. I think option 3
> is also a good solution. I don't think it's the repsonsibility of the
> application do to the clean up, but of the trash resource itself or another
> separate agent which is only responsible for cleanup.

That is indeed also an interesting idea. 

The problems i can see:
-the application would need to filter all items based on the deleted-attribute 
(could be done in the entitytreemodel)
-same for showing the trash folder (deleted items), maybe we could make use of  
virtual collections for this.
-Resources which do not store the data locally (i.e. google calendar), would 
have to delete the items from the google resource, while keeping them locally 
(special handling needed).
-With a global janitor agent it would be more difficult for applications to 
control when the items are really deleted (although possible

Advantage would be:
-It would work very well together with the idea that the resource decides if 
it delets the items directly or later. This way the whole trash configuration 
(directly delete/ trash, time before items are deleted, etc. ) could be 
included in the resource, together with a default ui 

> 
> > 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.
> 
> The resource could decide for itself what to do when an item is deleted. It
> could move it to trash, or just delete it.
> 

This could have some unexpected sideffects, like when two applications use the 
same resource, it might be unexpected for the user that suddly items are not 
moved to trash anymore, just because he changed the trash setting in another 
app.

I think it would still be a nice encapsulation of the whole trash 
functionality, so if we could override the default behaviour with the delete 
job, it would be a reasonable thing to do.

Cheers,

Chris

> > 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.
> 
> I'm not very familiar with how the special collections etc work, but I
> think there is a good solution to be found here. This was the subject of a
> GSOC project suggestion too, which no one took up. Kevin might know if
> there's more thought put into it somewhere.
> 
> All the best,
> 
> Steve.
> 
> > 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/