[Kolab-devel] Horde can now store Preferences in IMAP (was: Horde preferences: LDAP or IMAP?)

Thu Mar 13 08:22:14 CET 2008

Gunnar Wrobel <wrobel at pardus.de> writes:

> Stephane Konstantaropoulos <stephane at voyageonline.co.uk> writes:
>
>> 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.
>
> Thanks for the feedback. The LDAP preferences backend will definitely
> stay the default backend now. People convinced me :)
>
> The IMAP preferences backend might still find it's way into Horde CVS
> at some point. But it will be purely optional then.

The IMAP driver for preferences is available since yesterday within Horde.

While most people will probably use the older LDAP driver I want to be
able to have an "IMAP-only" Horde/Kolab with Horde 4.

Cheers,

Gunnar

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

-- 
______ 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 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~