[Kolab-devel] Horde can now store Preferences in IMAP (was: Horde preferences: LDAP or IMAP?)
Gunnar Wrobel
wrobel at pardus.de
Sun Dec 21 23:42:48 CET 2008
Hi!
A while back (beginning of this year) we had a discussion on how to
store the user preferences of the Kolab webclient (based on Horde).
Horde preferences are being handled by a single module called "prefs".
This module supports several backends. Among them are
- SQL
- LDAP
- File based
- IMAP
Horde usually uses SQL. Kolab has traditionally used the LDAP backend.
This LDAP backend has been replaced with the file based backend for
Kolab Server 2.2.1 beta 1. An alternative would also be the storage in
IMAP similar to the other groupware data of the Kolab server.
The decision to switch to the file based approach was made since the
developer team did not consider LDAP to be a decent place for such
data anymore. It makes the LDAP entries rather complex and LDAP is
usually meant primarily for read access rater than a standard storage
space.
We decided not to use IMAP at the moment as that would mean we would
need to discuss the Kolab format for such entries wich would take a
while until we finalize it.
So the file based approach has been selected for now.
This does not hinder anyone to choose any of the other possible
backends. People that like to remain on LDAP can do so without
problems while people preferring IMAP storage can also choose to do so.
But the question still is: What is the best default?
It would be great if people could add the pros and cons they see for
the different solutions. I'll try to add an overview once we have some
opinions and I'll include the relevant pieces from the discussion we
had at the beginning of this year.
I would like to add that I personally see the IMAP driver as the best
choice. For me the Kolab server architecture results in one simple
conclusion: User data belongs into IMAP. And preferences are user data.
Cheers,
Gunnar
Quoting Gunnar Wrobel <wrobel at pardus.de>:
> 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 <<
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> 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 <<
--------------------------------------------------------------------
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20081221/681137e4/attachment.sig>
More information about the devel
mailing list