[Kde-pim] Handling Virtual Collections/Resources in Akonadi applications

[Volker Krause]

On Thursday 13 August 2009 00:40:53 Stephen Kelly wrote:
> Tobias Koenig wrote:
> > On Wed, Aug 12, 2009 at 01:27:54PM +0100, Stephen Kelly wrote:
> >> The virtual resource could then be removed with another action, or
> >> whatever the Thomases decide.
> >>
> >> Most of the work on this will be done by me anyway, but I'd like to get
> >> good idea/bad idea concensus. Any thoughts on that?
> >
> > Hmm, we need an identifier for this for sure, but maybe we can add
> > another parameter
> >
> > enum Visibility
> > {
> >   Global,       ///< Search collection is visible for all application.
> >   Application,  ///< Search collection is only visible to application
> > with the given identifier.
> > };
> >
> > So the SearchCreateJob would have the following ctor
> >
> >   SearchCreateJob(const QString &name, const QString &query, Visibility
> >   visibility, const QString &identifier);
> >
> > The created search collection would contain a special
> > SearchVisibilityAttribute that contains the Visibility flag and the
> > identifier.
>
> Yes, an attribute would be a nice way to tell the ETM that it should show
> multiple virtual collections which should have more visibility.
>
> > The ETM would provide a method 'setSearchSession(const QString&)' where
> > the identifier of the application is passed that uses this instance of
> > ETM (e.g. kmail would pass 'kmail' ;)). Now the ETM could query all
> > search collection and evaluate their SearchVisibilityAttribute. If the
> > Visibility is set to Global, it is always included, if Visibility is set
> > to Application, the collection is only included if the identifiers match.
> >
> > Comments?
>
> Instead of inventing a new search session string, you could instead use the
> identifier of the Akonadi::Session you passed into ETM. ETM already knows
> that, and your application should too if it's kept around as m_sesssion or
> something.

The Akonadi::Session identifier is not persistent over application restarts. 
So, for persistent search folders we indeed need something else.

Tobias' approach looks quite similar to what we discussed yesterday though, it 
provides a way to namespace persistent virtual collections. We thought about 
doing that as collections hierarchy, but that's implementation details, I 
think we have to solve that on a conceptual level first.

> However, can you think of any use case for that? Would anyone actually run
> both KMail and Mailody and show the same search collections in both?

Absolutely. My use-case for that is to get rid of the physical folder tree 
eventually and have only virtual collections that represent the same tree,
but put my mails automatically where they belong.

> Can you think of a contact-type use case? 

A virtual folder tree representing tags should work as use-case for every 
type. And it's something you probably want to have available globally.

> Isn't it dangerous to set global 
> visibility on a virtual collection like that? The ETM in kaddressbook could
> obediently show a virtual collection of contacts which don't have a
> particular role being in KAddressBook. For example, if you have a plasmoid
> showing people who enjoy 'giraffes', and the plasmoid author decided to set
> global visibility on it, not knowing what the flag does.

I think we will always have this risk of applications polluting the global 
namespace, no matter how you implement it.

> KAddressBook would also obediently try to process a virtual collection
> containing emails that someone sets global visibility on. Of course, the
> SearchVisibilityAttribute could store a mimetype too for filtering, but
> then I'm again stuck on the use case part.

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/20090813/1ad118d0/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/