james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Draeger ...@joachim-draeger.de>
Subject Re: IMAP Draft: Quota
Date Wed, 05 Jul 2006 19:23:08 GMT
Hi Bernd,

Am Mittwoch, den 05.07.2006, 16:23 +0200 schrieb Bernd Fondermann:

> are you really making that good progress you are already discussing 
> advanced features, or are quotas required by IMAP?

Well, the progress is near to alpha for basic commands. What really is
needed now is starting an Imap capable storage back-end. 
As I pointed out in the roadmap draft, quota is IMO not a feature that
will be implemented in the near future. But sooner or later it will be
essential.
What I don't want to do is just hacking in a JDBC implementation and
throw everything away when the time has come for the next feature.
If we are aware of what we'll need in the future we could now try to
make the right decisions. 

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

I'm not sure.  It could mean adding 10000 values on each append/delete. But DBMS are
optimized to do such things very fast.

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

Yes, I agree that is is sufficient. But I'm not sure if it is much more
simple.

1. check if one of the quota objects is flagged overquoted
2. Start transaction
3. Store the header
4. Store the message 
5. update the total mailbox size
6. commit
7. calculate the occupied space for each quota object
9. set the overquoted flag if needed

It is maybe safer because it does not require locking of central
objects. Only the mailbox is locked (because of updating size) until the
commit.
So far the Quota
(http://www.joachim-draeger.de/JamesImap/proposal/org/apache/james/messagerepository/Quota.html)
interface only declares the function getStorageUsage(). Both ways are possible. 

> I don't think a 'quota' 
> means 'hardly enforced physical limit'.

I agree. On JDBC/RDBMS it is relatively easy, transactions should be
used anyway. In other implementations it might be more difficult, for
example when there are concurrent deliveries.

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

It was my intent to show how it could be done with JDBC. How to measure
getStorageUsage() and when to decide that it is overquoted and e.g.
throw an Exception is completely implementation specific. 
The approaches for JDBC and e.g. file-based will probably quite
different. There might even be limitations like only one quota per 
mailbox or quotas have to be hierarchically.

Joachim


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