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

[Stephane Konstantaropoulos]

Hello,

I fully agree with Alain, the LDAP preferences backend for Horde is efficient 
and is there, I see no point in creating a new one. Plus it is very easy to 
admin for shops that use LDAP for a lot of things, such as Samba or POSIX 
auth. We use LDAP as a backend for most of our users' stuff and it is very 
solid.

We store iPlanet prefs, Samba prefs, Posix prefs and user data in there and 
that's what it is there for.

I think you should stick to it with Horde, and perhaps see if you can optmize 
some stuff, like session caching or something.

My production Horde is slowed down by the Imap server more than the LDAP 
server. (a few thousand users).

My 2 cents

Stephane

Le Wednesday 03 October 2007 00:05:27 Alain Spineux, vous avez écrit :
> 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



-- 
Stéphane Konstantaropoulos
-- Creator, Web Applications
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20071030/6cbf31d2/attachment.sig>