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 ;-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
