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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
