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

[Alain Spineux]

On 10/2/07, Martin Konold <martin.konold at erfrakon.de> wrote:
> 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)

This is the way LDAP works.

LDAP is the perfect place to store data from different application
(but all related to the same object). Different apps can share the
same data from different place. LDAP provide ACL at
object and field level !

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

And how do you modify this file from remote location ?

You are designing file format, data access ... while LDAP already
exist, with all this stuff.
Why do you want to reinvent the wheel ?

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

just add a "include" in slapd.conf ... not to much works

>and the users can be plain KolabInetOrgPerson objects.

is it an advantage ?  Could not my users be samba users ? Or asterisk one ?

> In
> > addition this reduces LDAP read/write operations.

Do you need to economize LDAP, are imap or file access cheaper ?
You can cache these data into the PHP sessions data !

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

Sure ? completely hidden ? No risk for the user to erase this "strange" folder ?

>
> > 1) Do people regard it as a desired alternative to store the
> > preferences on IMAP? Any specific drawbacks or advantages I missed?

The main kolab idea was to retrieve/store all data from LDAP and then
kolabd was synchronizing them into IMAP (creating mailbox, .......)
Why do you want to put data somewhere else ?
Then why not write directly postfix, apache, cyrus template from the GUI ?

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

LDAP already provide this out of the box :-)

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

Still imagining powerful, but less standard data access ?

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

Did I already suggested you can use LDAP instead ? :-)

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

Yes IMAP is excel in storing /retrieving emails :-)

>
> > 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/
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>
>


-- 
Alain Spineux
aspineux gmail com
May the sources be with you