james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Draeger ...@joachim-draeger.de>
Subject IMAP Draft: Quota
Date Tue, 04 Jul 2006 14:28:00 GMT


Quota

Introduction

IMAP can be used to archive all your messages. This may include 15
apache.org high-traffic mailing lists and a complete collection of all
fun-ppt/fun-pics/fun-movies mails + attachments, your funny colleagues
have sent to you in the last 5 years. ;-)

Reaching a few GiB is possible. That is why setting up a quota might be
necessary. (If you are the sysadmin, you know that sending a daily
message to your users "please clean up your mailbox" is really futile.)
Sooner or later your boss will notice that you are deleting old messages
underhand...

Interfaces

see Quota and ImapMailboxRepository 

General

Quota objects are responsible for a list of mailboxes. They are not
treated hierarchically but have to be assigned to each mailbox
individually. When a mailbox is created or renamed, it has to inherit
the quota of its parent. 

Implementation of quota management could of course be done in a
hierarchy way. 

I came to the conclusion that it makes no sense to have user specific
quotas. E.g. user1 has a 100 MB quota for the whole namespace. He is
employee in the buying department. Why shouldn't he store an important
message into #shared.buying, just because he has exceeded his personal
quota? Forcing the buying department to clean up their shared mailbox
not to reach a limit of 1 GiB makes sense.

Root-Mailbox
Quotas are not hierarchy agnostic. One quota-object could be responsible
for a selection of mailboxes even across namespaces.

But this makes management of quotas very complex. It may even be
desirable to allow users to setup their own quotas e.g. for their trash
folder. This would also require checking credentials.

The approach is to allow setting a root mailbox for a quota. Only this
mailbox itself and children are allowed to be added. Users could be
restricted in only being allowed to setup quotas with a root mailbox
they have the "quota management" right for. quotas bound to a root
mailbox are more easy to browse in a management interface.

Many-To-Many

Because quotas are not hierarchy agnostic, they are not inherited
automatically. There are situations where a mailbox may be bound to
several quota object. E.g. #mail.user1.Trash has a quota of 10 MB setup
by user1. #mail.user1 has a quota of 100 MB setup by his local sysadmin.
"#mail" has a quota of 5 GiB and there is a system wide quota of 10 GiB
bound to all mailboxes.

This means "#mail.user1.Trash" is bound to 4 quota objects. If any of
the 4 quotas is exceeded he cannot store a message.

Quotas In JDBC

In a RDBMS each quota object should hold the current usage. It will need
too much time to compute it always on the fly. This means when a message
is appended to a mailbox every quota object bound to this mailbox has to
be updated. A system-wide quota object has to be update every time a
message is appended somewhere

Incrementing an integer value should not be so time intensive.
Transactions will guarantee a consistent state. 

This is how I think such a transaction could work:

     1. Fetch all quota objects bound to "#mail.user1.Trash" and check
        if there is enough space to try the transaction
     2. Start transaction
     3. Store the header
     4. Store the message (this may take long)
     5. update the quota objects ( No one else is able to update these
        quota objects anymore)
     6. Check if we are in the limit (doing a select now should give us
        the updated values)
     7. Commit if we are in, rollback if we are out

The weak point is that if there is a system-wide quota noone else could
append a message anywhere between 5 and 7. Do we have to worry about
that? Normally this could be done in a few milliseconds. The expensive
parts (storing content) are non-blocking.





---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message