[Kolab-devel] Modifying the LDAP user representation for a distributed Kolab server system?

[Bernhard Reiter]

On Tuesday 29 July 2008 11:55, Gunnar Wrobel wrote:
> I don't see a specific benefit for a completely separate FreeBusy
> server as described in the Horde bug I referenced. I think you'd need
> a lot of users in order to make that necessary.

I lack numbers, but my guess is that Horde is one or two magnitudes
more resource hungry than a native client user on a server machine.
So if you can have 200 native concurrent users, probably the same machine will 
only take 20 or less concurrent Horde users.

> But once you split your Horde installation to a different Apache
> server I believe it makes a lot of sense to combine FreeBusy with the
> Horde installation. The newer FreeBusy code uses the same IMAP cache
> as Horde does. So you can reduce the IMAP calls with this. A combined
> Horde/FreeBusy server also allows you to remove the complete apache
> from the main server which might be another reason for such a setup.
>
> I think I discussed this with Bernhard once and he disagreed but I'd
> have to look up the thread again.

Yes I disagree because freebusy is a part of the native client
for which people expect different response times. Web client usage is 
something very different from the user perspective. And I do not want 
web users to slow down native client users and email in- and outgoing 
processing.

So standard separation steps would be:
a) an an SMTP gateways with scanning
b) seperate web client server (Horde)

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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20080729/da55a3da/attachment.sig>