martin: doc/architecture concept.sgml, 1.10, 1.11 overview.sgml, 1.6, 1.7 server.sgml, 1.5, 1.6

[cvs at intevation.de]

Author: martin

Update of /kolabrepository/doc/architecture
In directory doto:/tmp/cvs-serv12232

Modified Files:
	concept.sgml overview.sgml server.sgml 
Log Message:
Martin K.: Added hard and soft quota


Index: concept.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/concept.sgml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- concept.sgml	17 Mar 2004 13:07:49 -0000	1.10
+++ concept.sgml	17 Mar 2004 17:56:42 -0000	1.11
@@ -12,8 +12,8 @@
 <book>
 
 <bookinfo>
-<title>Free Software Groupware Project</title>
-<subtitle>Architecture Paper</subtitle>
+<title>Kolab Free Software Groupware Project</title>
+<subtitle>Architecture Paper Version 2.0</subtitle>
 <authorgroup>
 <corpauthor><inlinegraphic entityref="erfrakon" fileref="erfrakon"></inlinegraphic> </corpauthor>
 <othercredit>

Index: overview.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/overview.sgml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- overview.sgml	17 Mar 2004 09:57:04 -0000	1.6
+++ overview.sgml	17 Mar 2004 17:56:42 -0000	1.7
@@ -1,4 +1,4 @@
-<chapter><title>  Free Software Groupware Overview </title>
+<chapter><title>  Kolab Free Software Groupware Overview </title>
 
 <para>This highly scalable and secure solution is strictly based on a 
 client/server architecture.The server part of the groupware solution, herein 

Index: server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/server.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- server.sgml	17 Mar 2004 13:07:49 -0000	1.5
+++ server.sgml	17 Mar 2004 17:56:42 -0000	1.6
@@ -158,17 +158,74 @@
 transport_maps			Static SMTP Routes
 virtual_maps			Virtual Address Mapping
 </programlisting></para>
-<para> We decided to not use postfix's LDAP features for the Kolab server in the first run. </para>
+<para> We decided to not use postfix's LDAP features for the Kolab server in the first run. 
+</para>
 </sect2>
 
+<sect2><title>Cyrus Quota</title>
+<para>
+Quotas allow server administrators to limit resources used by hierarchies of mailboxes on the server. 
+</para>
+<para>
+The Cyrus IMAP server supports quotas on storage, which is defined as the number of bytes of the relevant RFC-822 messages, in kilobytes. Each copy of a message is counted independently, even when the server can conserve disk space use by making hard links to message files. The additional disk space overhead used by mailbox index and cache files is not charged against a quota. 
+</para>
+<para>
+Quotas are applied to quota roots, which can be at any level of the mailbox hierarchy. Quota roots need not also be mailboxes. 
+For the Kolab Server we limit ourself to top level quota roots. This means we only apply quotas to the complete mailbox of a user 
+(root of an individual account) and to the root of shared folder hierarchies.
+</para>
+<para>
+Quota roots are created automatically when they are mentioned in the setquota command. 
+Quota roots may not be deleted through the protocol. We automatically create the quota roots when applying the initial
+quota values to the quota roots.
+</para>
+<sect3><title>Hard Quota</title>
+<para>
+Normally, in order for a message to be inserted into a mailbox, the quota root for the mailbox must have enough unused storage so that inserting the message will not cause the block quota to go over the limit. 
+</para>
+<para>
+Mail delivery is a special case. In order for a message to be delivered to a mailbox, the quota root for the mailbox must not have usage that is over the limit. If the usage is not over the limit, then one message may be delivered regardless of its size. This puts the mailbox's usage over the quota, causing a user to be informed of the problem and permitting them to correct it. If delivery were not permitted in this case, the user would have no practical way of knowing that there was mail that could not be delivered. 
+</para>
+<para>
+If the usage is over the limit, then the mail delivery will fail with a temporary error. This will cause the delivery system to re-attempt delivery for a couple of days (permitting the user time to notice and correct the problem) and then return the mail to the sender. 
+</para>
+<para>
+The Kolab clients must bea able to handle the hard quota limit and provide a localized and meaningful error message. 
+The message which could not get synchronized must remain in the folder. User is ask to manually solve the problem e.g.
+deletion of messages.
+</para>
+
+<para>
+Each maintainer of a domain gets a daily quota report via email. This report has different sections for hard quota, soft quota and filesystem usage for everyone else. The frequency or disabling of this feature is 
+configurable by an administrator. (No GUI currently)
+</para>
+<para>In order to be able to deal with quotas correctly the KDE client must first delete messages before trying to send new messages.
+</para>
+</sect3>
+
+<sect3><title>Soft Quota</title>
+<para>
+When a user selects a mailbox whose quota root has usage that is close to or over the limit and the user has 
+<filename>d</filename> rights on the mailbox, the server will issue an alert notifying the user that usage is close to or over the limit. The threshold of usage at which the server will issue quota warnings is set by the 
+<filename>quotawarn</filename> configuration option. 
+</para>
+<para>
+The server only issues warnings when the user has <filename>d</filename> rights because only users with <filename>d</filename>
+ rights are capable of correcting the problem. 
+</para>
+</sect3>
+
+</sect2>
 </sect1>
 
 <sect1><title> Cyrus IMAP Daemon </title>
 <para>Cyrus is a widely-spread IMAP daemon for Unix environments. It stores emails using the maildir format.
 That basically results in a directory structure with each email represented by single file.
 The IMAP users are managed completely separate from the GNU/Linux system accounts. User quotas and
-access control list are provided by the daemon independent of the operating system.</para>
-<para>Cyrus' most interesting feature is it's excellent scalability. A single Cyrus instance can
+access control list are provided by the daemon independent of the operating system.
+</para>
+<para>
+Cyrus' most interesting feature is it's excellent scalability. A single Cyrus instance can
 serve up to thousand simultaneous interactive IMAP users.
 The performance of the
 filesystem storage and the network bandwidth/latency largely determin the maximal scalability.