Request for Input: Storing Searches
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Tue Aug 30 15:03:29 CEST 2011
Christian Mollekopf wrote:
> Something along the lines of tagging the search results via the ANNOTATE
> Extension and using an XML object will probably gives us the most
Searches may or may not include non-IMAP content (such as LDAP content).
Why / How would a Kolab XML object help? Why not save the information in a
"virtual" IMAP folder?
This IMAP folder can handle the ACLs, thus be shared, it shows up empty for
clients that are unable to handle KEP #9, and *at your option* could be
prepopulated with the results of the search (OPTIONAL) - though the tradeoff
would be data duplication.
> There are however some problems existing:
> On the Akonadi side searches are afaik implemented as virtual folders which
> are populated based on a nepomuk query(sparql). Searches don't belong to a
> single resource however, since you can search accross various resources.
This is a client-side (saved) search, that cannot be shared with any other
We are attempting to put the saved search on the server-side somehow.
> This means we would have to implement that functionality from outside of
> the kolab resource I reckon.
What do you mean by 'the kolab resource'? An account? A folder? A single Kolab
XML object? The yet-to-be-defined Kolab saved-search XML object?
> - The action would then pick the results from the search which are in this
> resource, and tag them via ANNOTATE and create an xml object with the
> search info.
Where would this XML object be put?
> From here were going the same path if we are consumer or creator of the
> - The resource creates a virtual-folder inside the resource i.e. "Shared
> Searches/Last Search" (The name can be edited and is stored to the xml
> object), based on the xml object.
"the resource" and "the resource" keep confusing me. Also, "Shared searches"
implies the searches are shared... I think "saved searches" are more
> - The resource populates the virtual folder with virtual items based on the
> => - No data duplication
This has always been "optional"; a saved search folder *could* be pre-
Imagine a saved search across 5 contact folders with 10.000 contacts on
When NOT pre-populating the saved search folder with the search results, you
pay the cost every time the folder is opened. Maybe this cost is not so great
for a fat client with a local cache to query
(Kontact/akonadi/nepomuk/Disconnected IMAP), but for a web-interface...
When pre-populating the saved search folder with the search results, you pay
the cost in "duplicate" storage (as explained, not on the server side, perhaps
on the client side if it's not intelligent enough to de-duplicate).
Another penalty in pre-populating the saved search folder could, arguably, be
that perhaps there's results in said saved search folder that the person using
the folder would otherwise not have access to. However, this can also be
considered a feature; "Share all contacts from Vendors folder tagged with
'ict' with helpdesk personnel"
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the format