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 Mon, 10 Jul 2006 14:18:11 GMT
Joachim Draeger wrote:
> Am Samstag, den 08.07.2006, 13:41 +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!
> That would be great! At the moment I make only sporadic changes to the
> draft API interfaces on SVN.

I'd more or less stick to your JIRA postings/attachements (as JIRA is 
one of our 'official' project resources).

> Things would get more dynamic with external input. :-) It's really
> difficult to fit every need and to keep things simple.

can't promise anything, but at least it's on my agenda.

>>Also, we have to keep in mind how to integrate your code with the James 
>>codebase. But that's for another thread...
> I think a lot about that. I also have some ideas. One question is for
> example how could James benefit from a logical namespace for message
> repositories / mailboxes? 
> But IMO the first solution will be to allow optionally plugging in the
> namespace/hierarchy aware repository and using wrappers for legacy code.
> (a NamespaceMailRepository implementation).
> So the codebase keeps stable.

namespaces for repos is something which is also going around in my mind 
for some time. maybe we should have a separate discussion about it in 
near future!

>>BTW, are your propositions based on RFC 2087 or is this another beast?
> I did it according to RFC 2087 and JavaMail. The procedure I described
> as a proposal for JDBC is just a possibility not a requirement.
>>>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.
> "Waterfall model" is really getting a swear-word in today's agile
> development world, isn't it? ;-)

;-) it is - I apologize, didn't want to swear at you... ;-)

> No waterfall model, just an overview. No complete elaborated plan, just
> a few thoughts and drafts. And I promise just to skip thinking about
> quota right now, because it should be enough as an overview. :-)

we could go on. but we must keep in mind the whole discussion is 
repeated in the future when quotas eventually are reconsidered. ;-)


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

View raw message