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

[Martin Konold]

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? 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 

> 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.

> The second question is important since we would need to ship the
> driver with the earliest release possible. Otherwise we might get
> people running this in production that will have to run "preferences
> conversion scripts" (that would have to be written) if we ever change
> the default option.

Regards,
-- martin konold

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstraße 23 Stuttgart - Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20071002/0651f41c/attachment.sig>