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.

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

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.