< PIM | AkonadiRevision as of 08:22, 9 September 2009 by Vkrause (talk | contribs) (Start to collect notes on virtual collections and all the related stuff.)(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff) 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. Retrieved from "https://community.kde.org/index.php?title=PIM/Akonadi/VirtualCollections&oldid=53756" Category: Akonadi Content is available under Creative Commons License SA 4.0 unless otherwise noted.