kolabd package available in Debian sid

[Tobias Koenig]

On Wed, May 10, 2006 at 07:42:54PM +0200, Jan Schneider wrote:
> Hi,
Hi,

> I would like to get Tobias König into the loop, I don't know if he's  
> subscribed to the kolab-users mailing list.
I'm just subscribed to kolab-dev ;)

> >>bugdb (http://bugs.horde.org/ fill in 'kolab' in the summary field), there
> >>aren't too many issue's.  Especially not design issue's...
... and some of them couldn't be reproduced with current version, so
even less bug reports left.

> >I have had several developers that have deeply looked into the code say
> >that they cannot bring Horde as Kolab Client into a stable,   
> >maintainable state.
> 
> I doubt that, as Tobias' work has proved.
Right, getting up a Horde as Kolabfrontend is possible. The Share-Sync
code needs some update though, but when that is done, it's equal to
other kolab clients from a technical point of view.

> >What my understanding of the design problems is:
> >
> >	a) the use of the database versus Kolab's design of imap folders.
> >           It will create almost unsolvable sync issues and hurt stability.
> >           And if the code is spread throughout
> >           Horde, this will be hard to change.
> 
> Horde does not have an inherent database driven design. Quite the  
> contrary, it has a driver based design. This made it possible to write  
> Kolab drivers for the several applications so quickly. There is this  
> DataTree thingy that still causes a lot of headaches because it's the  
> last remaining database dependency in Horde, but solutions for this  
> problem have already been discussed in the past.
Correctly, the kolab driver reads the data objects directly from the
imap server when the user logs in and saves them to the imap server on
modifications. So no additional database is involved.

> >	b) Horde needs higher privileges. This is in contrast
> >	   to the Kolab-Webinterface that only works with the
> >           priviledges of one user. If true, this would hurt the security.
> >           Note that database application are often designed this way,
> >	   Kolab can do differently which is a plus.
> 
> I'm not sure if this is true, and I'm wondering if this is really a  
> general design issue in that case. I guess it could be solved.
Indeed, the higher privileges shouldn't be necessary, they can be
decreased to the user nobody for uid/email -> dn lookups and the normal
user rights for data object modifications.

Ciao,
Tobias
-- 
Separate politics from religion and economy!
The Councile of the European Union is an undemocratic and illegal institution!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.kolab.org/pipermail/users/attachments/20060511/33f08990/attachment.sig>