Projects/PIM/Akonadi/VirtualCollections

< Projects‎ | PIM‎ | Akonadi
Revision as of 09:22, 9 September 2009 by Vkrause (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

All about virtual resources, virtual collections and searching.

Use-Cases for Virtual Collections

  • Representing the results of a persistent search:
    • in a per-session scope, e.g. the currently displayed week in KOrganizer
    • in a per-application scope, e.g. user-defined persistent search folders in KMail
    • in a global scope, e.g. user-defined persistent search folders shared between KMail, Mailody and LionMail.
  • The Nepomuk tag resource
    • Representing the entire tag-tree

Ideas on the Search Infrastructure

  • Delegation to resources that support search in the back-ends
    • Requires query transformation
    • Requires management for live searches
    • Requires the ability to report search results (needs protocol extension)
  • Query language still undecided, current options: XESAM, SPARQL
  • Back-end still undecided, current options: XESAM, Nepomuk

Akonadi Search Infrastructure (concept)


Virtual Collections

The following lists properties of "normal" Akonadi::Collection objects and maps them to the corresponding semantics of virtual collections:

  • UID: stays the same
  • RID: for application use (currently it holds the query, but that's a dirty hack) (search folders only, still used for its original purpose by the tag resource)
  • Name: stays the same, for display purposes only
  • Resource Id: see virtual resources
  • Content mime-types: good question actually...
  • ACL: extend by link/unlink operations
    • Item creation: not allowed, would lack a storage location
    • Item modification: in theory possible if the storage collection allows it
    • Item deletion: in theory possible if the storage location allows it
    • Collection creation: depends on resources, useful for the Nepomuk tag resource, not for persistent search folders
    • Collection modification
      • Name: no problem
      • RID: not allowed once there is a actual resource behind it, not a problem when used by the application
      • Query: requires special support in the server, but no principal problem
      • Parent (that is moving): tricky for the tag resource, not really a problem for search folders, moving to non-virtual resources needs to be prevented.
      • Any other attribute: no problem
    • Collection deletion: no effects on stored items/collections, so no problem
  • Query: for search folders only, should be moved into an dedicated attribute.

KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal