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