[Kolab-devel] Horde can now store Preferences in IMAP (was: Horde preferences: LDAP or IMAP?)
Bernhard Reiter
bernhard at intevation.de
Mon Jan 5 10:19:55 CET 2009
On Freitag, 2. Januar 2009, Alain Spineux wrote:
> > Horde usually uses SQL. Kolab has traditionally used the LDAP backend.
Ah, the us of "traditionally" is missleading, the Kolac Concept never
suggested putting client user preferences into LDAP.
In fact there has been no solution for this so far, so the clients
are on their own saving their settings.
The Kolab Web Client (based on Horde) is a Kolab Client, but a special one.
This is what makes the discussion interesting. The use of LDAP for
daily client preferences in Kolab Server 2.2.0 was by mistake.
> > This LDAP backend has been replaced with the file based backend for Kolab
> > Server 2.2.1 beta 1.
> > 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.
> > But the question still is: What is the best default?
Until we have a good proposal for the Kolab Format, it should be file,
as this is what most other clients also use.
> > 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.
You'll have this anyway with all clients (unfortunately.)
> 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 ?
A client could potentially write this data on any display refresh
or client action. Just think about index files that contain special flags
per email. So I guess that there will be always client data that will need
to be saved client locally per user.
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20090105/1e40650a/attachment.sig>
More information about the devel
mailing list