Request for Input: Storing Searches
mollekopf at kolabsys.com
Tue Aug 30 16:11:49 CEST 2011
On Tuesday, August 30, 2011 02:03:29 PM you wrote:
> 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.
True, I thought by using something else than an empty folder we don't have to
hide the empty folder. Otherwise I guess an IMAP folder per search would do as
> > 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?
Yes, that is 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?
Sorry for not being more specific. Whenever I used the word resource I am
referring to an akonadi resource (aka agent).
The connection to kolab is in akonadi realised as a kolab-resource which
handles all the kolab specific bits and then exposes the data with
message/rfc822 messages. In a similar way there exist resources to access
email from pop3 servers etc. you get the idea.
See http://community.kde.org/KDE_PIM/Akonadi for more info.
> > - 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?
I'd imagine that we put those objects in the rootfolder or in a "Saved
Searches" folder. In the "Saved Searches" folder we could then also create the
optional server-side populated search directories.
> > 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
Yeah, my "shared" was more referring to shared among different machines,
Saved searches are probably more appropriate.
> > - 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...
Yes, since akonadi can create virtual folders it only has to populate them
once AFAIK, and then result is then cached.
For a webclient I guess you're right. But if we have the dataduplication and
it should also be writable it looks somewhat error prone to me.
Especially if we have to implement that for every client.
I reckon using akonadi as a cache for the webinterface would solve that
> 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).
Well, the argument for doing it server side would be that it is available on
any client (i.e. smartphone), but then read-only is the only option i see.
If it is on the client side, this ends up to be essentially the same as the
akonadi virtual folders.
> 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"
If it is being populated on the client side I don't see how you could get
access to items you shouldn't have access to.
With my best regards,
> Kind regards,
> Jeroen van Meeuwen
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the format