[Kolab-devel] Horde preferences: LDAP or IMAP?
Gunnar Wrobel
wrobel at pardus.de
Thu Nov 1 12:13:38 CET 2007
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.
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 <<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the devel
mailing list