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

Wed Oct 3 10:57:38 CEST 2007

"Alain Spineux" <aspineux at gmail.com> writes:

> 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

Yes, it is not too complex :) There is a little bit more that needs to
be done from the packagers point of view but that is also nothing
major.

>
>>and the users can be plain KolabInetOrgPerson objects.
>
> is it an advantage ?  Could not my users be samba users ? Or asterisk one ?

Of course. I guess I only mentioned it because the webadmin frontend
had problems dealing with it. This has been fixed anyhow.

>
>> 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 disagree. As I mentioned in my response to Martin we do store the
majority of user data (the groupware data) in IMAP. The amount of user
specific data in LDAP currently is trivial.

>>
>> 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 :-)

Hm? The IMAP based preferences driver is of course email-based as are
all the other groupware elements in Kolab are too. I'm just using the
central Kolab module in Horde there so it is the same mechanism as for
notes, tasks, events and addresses. Nothing fancy.

One thing you disregarded in your answer: The LDAP write
processes. You will get quite a few of these from Horde. The values
are read ONCE and cached during the users web session. But there will
be instant write-back of values into LDAP once a page request got
processed and involved a preferences change. It may be that this is no
big deal for LDAP but I don't know.

In any case you will have the choice to choose either LDAP or IMAP as
the admin of your system. The question for me right now is only what
we should offer as a default and if it makes sense to get the IMAP
based driver in shape so that we can offer it with the next beta.

I guess you are in favor of LDAP as a default ;)

Cheers,

Gunnar

>
>>
>> > 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
>>
>>
>
>
> -- 
> Alain Spineux
> aspineux gmail com
> May the sources be with you
>
> _______________________________________________
> 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 <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~