[Kolab-devel] Horde preferences: LDAP or IMAP?

[Gunnar Wrobel]

Martin Konold <martin.konold at erfrakon.de> writes:

> Am Dienstag 02 Oktober 2007 schrieb Gunnar Wrobel: out
>
> Hi Gunnar,
>
> thanks for taking up with this initiative. 
>
> I am also not very happy with the current LDAP approach which clutters up the 
> LDAP namespace very much and looks more like an abuse than like a useful 
> directory. (e.g. many unused empty entries)
>
>> I regard LDAP as a bad storage place for the web client preferences
>> and wrote a new preferences driver for Horde that uses an IMAP folder
>
> Why did you rule out the simple option to use a plain file for each user?

I guess in my mind the data storage on a Kolab server is divided
roughly into:

 - IMAP -> user data
 - LDAP -> server data
 - File -> temporary data

This is of course no strict rule since we also have some user data in
LDAP and some important server settings in files. But I still like to
think of it like that and so I did not consider a file based
preferences as a first option. The main advantage of this data
separation would be the backup: I feel that backup of a Kolab server
is rather trivial and there are not too many storage places I have to
think about when storing/recovering a server. And the user can of
course easily retrieve all of his/her data by simply syncing the imap
store.

This is just to explain why I didn't consider it. The file based store
you describe is certainly possible and does not have the "special
folder" disadvantage.

> If 
> this plain file is protected using Apache access control it would be trivial 
> to make it available anywhere whithin a Kolab server cluster. E.g. you could 
> store the file on the kolabHomeServer and use a URL like 
> https://kolabhomeserver.domain.tld/config/horde-preferences. Because horde 
> knows the users credentials it would be trivial to provide them to Apache. 
> Using these credentials Apache or some php script could internally use the 
> correct user specific file
>
> If figuring out the kolabhomeserver via LDAP is not an option it could be 
> handled trivially by the php script running on any server in a transparent 
> manner.
>
>> The advantages of this driver: The LDAP schemas don't have to be
>> modified and the users can be plain KolabInetOrgPerson objects. In
>> addition this reduces LDAP read/write operations.
>
> I fully agree!
>
>> The disadvantages: There is a new folder type and the other clients
>> might display a "Preferences"-Folder with mails they can't really use.
>
> Well, you would still have the option of "hiding" this special folder from 
> other clients using ACLs and subscription state.
>
>> 1) Do people regard it as a desired alternative to store the
>> preferences on IMAP? Any specific drawbacks or advantages I missed?
>
> I think that IMAP is an option while a plain URL pointing at some trivial PHP 
> script is better. This script could provide transparency in case of a 
> clustering setup and as an added bonus it could allow trivial REST features.
>
> This means that calling the script without parameters e.g. 
> https://kolabhomeserver.domain.tld/config/horde-preferences will provide a 
> single document with some trivial file format (e.g. key=value or some simple 
> XML). E.g. in doing a HTTP GET to 
> https://kolabhomeserver.domain.tld/config/hordePrefs would provide something 
> like:
>
> [...]
> summary_refresh_time=10
> show_sidebar=true
> sidebar_width=40
> menu_refresh_time=100
> [...]
>
> On the other hand 
> https://kolabhomeserver.domain.tld/config/hordePrefs?action=get&key=show_sidebar 
> would return a document only containing the string "true". If the 
> implementation benefits returning "show_sidebar=true" is also an option.
>
> In this simple model it would be the job of the horde application to know that 
> the string "true" refers to a bool. Doing so is imho trivial in case of 
> horde. This would allow to limit the capabilities of the preference storage 
> service to simple strings.
>
> The php script hordePrefs.php would trivially be able to distinguish the users 
> from the mandatory credentials. 
>
> The actual backend used (e.g. a flat file or a small berkley DB) is then a 
> simple opaque implementation detail.
>
> Storing a single key would be done using an URL like 
> https://kolabhomeserver.domain.tld/config/hordePrefs?action=set&key=show_sidebar&value=false 
>

Can't disagree. It is possible to do it in the way you describe it. I
guess that the coding effort would be comparable to the IMAP based
driver since you need to add code on both sides (Kolab server and
Horde).

>> 2) If this driver should be available what should be the default
>> option?
>
> IMAP is definetly better than LDAP but imho other options like my proposal 
> should be considered.

Since we wanted to have the next release including Horde by the end of
next week I guess we only have the decision between LDAP and IMAP at
the moment. The LDAP driver has always been available in Horde, the
IMAP driver is available as a draft version
(http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE_CVS/file/tip/framework/HK-GW-Prefs-Kolab_IMAP.patch),
but the file based version would have to get written.

The administrators will have the option to choose the different
drivers in Horde. So if we only offer LDAP in the beginning they can
still choose IMAP or File at a later point once they become available.
They will need a conversion script then or they will have to drop all
user preferences. The second choice is not really an option though :)

Cheers,

Gunnar

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                           Bundesstrasse 29
Fax    : +49 40 432 70855                            D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~