Request for Input: Storing Searches

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Sun Oct 2 19:14:31 CEST 2011


Aleksander Machniak wrote:
> A few more thoughts to discussion.
> 
> 1. About pre-populating and sharing. Imagine user A which searches in
> shared folder Folder1 to which he has access. Pre-populating means
> contacts will be copied to new saved-search folder, right? Now, user A
> gives access to his saved-search to user B, but user B has no access to
> Folder1. This way non-admin user can get around ACL in one simple move.
> Of course he could also copy the contacts to owned folder and share it,
> but...
> 

This is a problem of discretionary access control as opposed to mandatory 
access control, and not a problem at the basis of saved-searches.

User A does not have to use a saved-search to disclose to User B any 
information to which User A has access.

> 2. About sharing and usability. Let's say we have a hundred users and
> all have at least one (his own) saved-search shared with others. I'm one
> of them, do I really need to see a list of hundred saved-searches? I
> don't. Do you plan to use folder subscriptions to limit displayed items?
> 

One would use folder subscriptions to limit the number of folders displayed in 
(a) client. A concept such as 'local subscriptions' like Kontact has, 
basically making the client 'ignore' the folder even though it is subscribed 
on the server, could allow further flexibility.

> 3. Another thing. Creation of saved-search as IMAP folder will limit
> possibility to create generic folder with the same name.
> 

Yes. Similarly, I can not create a mail folder INBOX/Calendar.

> 5. If we decide to create folders for saved-searches consider creation
> of specific folder type for them, e.g.
> /vendor/kolab/folder-type=contact.search. This will simplify listing of
> folders (and saved-searches).
> 

We also have to consider SPECIAL-USE here, and what allows us to potentially 
move to that best choosing between the options we have today.

Creating a folder-type=contact.search will largely negate the value of pre-
population, which is supposed to allow clients not compatible with the latest 
and greatest KEPs to still see a regular contact folder.

Obtaining the second annotation (either /vendor/kolab/search in this case or 
/vendor/kolab/folder-config, depending on the outcome of the other discussion 
we're having) is a prerequisite in quite the bunch of operations, and cached, 
so I'm not sure what the cost is at the side of simplifying the listing of 
folders.

> All in all I think it would be much simpler and clearer to get rid of
> sharing and prepopulating features from the spec. ;) I thought the main
> idea was to share searches acros client software. Maybe we're going to
> overact the feature to much.
> 

Sharing saved searches was something that, indeed, was added to the 
specification later on. It was not initially targeted as far as I know, but we 
have to consider "what happens" should the IMAP folder - which just so happens 
to be a saved search - be shared.

Also, we have to consider the weight of operations if a saved search folder is 
to be populated real-time rather then be pre-populated, as searching a bunch 
of email folders the size of mine can easily take a few hours.

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/20111002/10288cbc/attachment.html>


More information about the format mailing list