Request for Input: Storing Searches

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at
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
> flexibility.

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 
client, correct?

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
> search:
> - 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
> tags.
> =>  	- 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"

Kind regards,

Jeroen van Meeuwen

Senior Engineer, Kolab Systems AG

e: vanmeeuwen at
t: +44 144 340 9500
m: +44 74 2516 3817

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the format mailing list