[Kolab-devel] Horde can now store Preferences in IMAP (was: Horde preferences: LDAP or IMAP?)
Alain Spineux
aspineux at gmail.com
Fri Jan 2 13:36:13 CET 2009
2008/12/21 Gunnar Wrobel <wrobel at pardus.de>:
> 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.
Pro IMAP too.
File based approach require to add something into the backup or the
migration procedure.
Anyway, when does these data need to be READ or WRITTEN ?
At each mail access, or at each folrder access, or just once at login
and logout ?
>
> 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.
>
> _______________________________________________
> 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
More information about the devel
mailing list