james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: IMAP Draft: Quota
Date Wed, 05 Jul 2006 14:23:07 GMT
Joachim,
are you really making that good progress you are already discussing 
advanced features, or are quotas required by IMAP?

Quotas should be a generic James concept, not something restricted to 
IMAP. As the whole Repository/Mailbox architecture should continue to 
not be protocol agnostic.

more inline...

Joachim Draeger wrote:
> 
> 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. ;-)

:-) ok, quota is a good thing. I'm convinced.

> 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.

+1 for "Quotas are working per Mailbox/UserRepository."

> 
> 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

If you'd separately store the size of every mailbox folder (and not 
recalculate from contained messages), it would not be too expensive I 
think to calculate totals by traversing the tree.

> 
> 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

Why not do the storing anyway, check afterwards if the quota is 
exhausted and flag or lock the mailbox until it has been emptied? seems 
much more simple approach yet still sufficient. I don't think a 'quota' 
means 'hardly enforced physical limit'.

Also, I'd like to see this independent of any database/JDBC 
consideration. that'd be too implementation-centric for now.

   Bernd

---------------------------------------------------------------------
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