Request for Input: Storing Searches

[Jeroen van Meeuwen (Kolab Systems)]

Georg C. F. Greve wrote:
> Allow me to higlight a couple of scenarios with advantages and
> disadvantages:
> 
>  - Scenario 2: Creation of new folder type w/KEP #9 annotation for
> metadata, create one folder per saved search
> 
> In this approach we'd create a new folder of the corresponding resource
> folder type for each search which would be identified as a stored search
> folder by existence of the /vendor/kolab/saved-search annotation

Please note a unique annotation is technically not sustainable, because all 
annotation keys need to be listed in a static list in a configuration file on 
the server-side.

It's better to use /vendor/kolab/folder-type contact, with a 
/vendor/kolab/folder-config holding the saved search data such as, for 
example, the following snippet;

> which
> carries the metadata for the search in an array, e.g.
> 
> 	{ 'saved_search':
>     		{ 'search_locations': 'blabla',
>       		'params': 'blabla',
>       		'filter': 'blabla',
>       		'fuzzyness': 'blabla',
> 		'async': '0'
> 		....
>     		}
> 	}
> 
> and the folder would be populated with the results of the search.
> 

Please note that the folder *could* be populated with the results of the 
search. I think this is an option.

> This DOES mean data duplication on the client, but Cyrus does allow to
> deduplicate entries on the server side, so it would not affect storage
> there. I am sure something similar would be possible with Dovecot, so
> we can for the moment assume data gets duplicated on the client only.
> 
> Advantages: Allows clients without search functionality to use results,
> can be automatically regenerated on the server if needs be, least CPU
> usage, works on email.
> 
> Disadvantages: Data duplication on the client, possible data set de-
> synchronization (e.g. contact gets edited in search results, same contact
> in main box and other search results boxes must be updated, this may be
> hard to ensure), increases folder clutter, some folder sharing questions.
> 

Populating the folder with the results would indeed duplicate the 
contacts/events/mail/whathaveyou. However, it would be a MUA problem to solve 
editing an object from within the saved search (prevent editting, warn user 
about editing this copy of the object, or replicate the change back to the 
original source of the search result -note the object's UID is available in 
the search results).

Perhaps the IMAP folder could be made not-writeable. This could have 
implications on the ability to edit the saved search though.

>  - Scenario 3: Map searches with tags
> 
> 	As a Kolab object, each search will carry an ID. If we were to 
introduce
> 	a new email header flag in storage that can carry an arbitrary number
> 	of tags, we could tag each object with the ID of every search that it
> 	matches.
> 

There is a concept called IMAP Flags, and a concept of RFC 5257 per-message 
annotation. Why would we need to insert a header into an email message?

> Likewise, if you can think of a scenario that should be considered in
> addition to the ones listed here, please let me know. As for the scenarios
> listed, there are two questions in particular that I wonder about:
> 
>  (a) Compatibility with clients, in particular: How will this integrate (or
> 	not) with the new Nepomuk/Akonadi KDE Kontact basis
> 
>  (b) Query language: How do we best formulate/store the query in these
> 	scenarios?
> 
> Anyhow, these are my thoughts on the matter right now.
> 
> I'd be happy to start drafting on something once we've identified which
> direction things should go into, but right now I still am not sure which is
> the path to go.
> 

These paths do not have to be mutually exclusive. A contact folder-type with 
folder-config annotations for a saved search does not inherently prevent a 
Kolab XML object with configuration for a search based on tags/flags/other 
message metadata (From, To, ...).

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20110830/2b53f0a1/attachment.html>