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 Sat, 08 Jul 2006 11:41:18 GMT
Joachim Draeger wrote:
> 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. 

It is great how hard you are working on the IMAP topic. I hope to get a 
chance to review it soon!

Also, we have to keep in mind how to integrate your code with the James 
codebase. But that's for another thread...

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

I consider Quotas quite a big feature for James as a whole, but 
"essential"? I don't know... probably depends on the user requirements.

BTW, are your propositions based on RFC 2087 or is this another beast?

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

well, this sounds like the waterfall model to me. let's make decisions 
when decisions are due, it's impossible to take everything into account 
beforehand. And I don't think you'd have to "throw everything away", if 
you'd skip thinking about quota now. instead I think one can yield much 
better results by concentrating on current tasks.

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

To make this more clear, my proposition was to store only folder sizes 
somewhere, never computed sizes. Computed totals could be done using 
SELECT (in the DBMS case). Each add/delete would result in changing the 
size for exactly one folder.

But it's way to early to optimize unwritten code ;-)


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

View raw message