Request for Input: Storing Searches
machniak at kolabsys.com
Thu Sep 29 11:20:44 CEST 2011
On 27.08.2011 20:39, Georg C. F. Greve wrote:
> - Scenario 1: Storage with a new KEP 9 based XML object
> One could attempt to model this as a "search" XML object that would
> incorporate the fields of the object type searched, plus some special
> fields, e.g. folders to search, as well as searches across multiple fields
> and search logic (AND/OR etc),
> These objects would live in the regular folders for resources, and would
> potentially even replace the list object in functionality, as they would
> then model a list of recipients as list of address book entries, which is
> something that Alain once suggested. 
> Advantages: Fairly close to existing functionality, and likely not too
> hard to implement for most clients (in comparison, at least), no data
> duplication anywhere.
> Disadvantages: Expensive on the CPU, Does not work on all resources
> because we cannot store these XML elements in email type mailboxes.
If we could go with this scenario I'd propose a modification.
Let's create more XML object types, e.g. contact.search, mail.search,
event.search (maybe with 'configuration.' prefix). Then we should store
them in 'configuration' folder (KEP:9). So, in configuration folder
we'll have many objects with different 'application/x-vnd.kolab.*' type.
This solution will be simple to implement and good for caching purposes
(config updates will be simple to detect). Also fetching objects by type
will be simple (search for X-Kolab-Type header) and not expensive (maybe
faster than annotations if IMAP server could create index for this header).
All in all I think this method would be a nice change to KEP:9. I mean,
create more object types instead of one (get rid of 'type' field from
the object format). This way client could query only for objects it's
interested in (it supports).
Another idea would be to define X-Kolab-Name header which could be used
for saved-search name. This way to present the list of saved searches we
wouldn't need to fetch complete objects, but only uid and the header (in
case the cache is disabled/not used).
Aleksander 'A.L.E.C' Machniak
LAN Management System Developer [http://lms.org.pl]
Roundcube Webmail Developer [http://roundcube.net]
PGP: 19359DC1 @@ GG: 2275252 @@ WWW: http://alec.pl
More information about the format