> 1) IMAP - I think this one is going to be on most people's list.
It may be on everyone's list, but I would not trust it for the release. It
isn't ready, and I would not want to hold up the release.
We can always put out a post-2.1 beta with IMAP included, but I would not
hold up a stable SMTP/POP release waiting on IMAP.
> 1) TLS Support for POP3 - This is really a rather simple piece
If it is simple, fine. Bug fix == good, new features == next go-round.
> Internal Documentation
Absolutely necessary. But NOT to hold up the 2.1 release. We can continue
to upgrade the web site with new documentation, and any serious developer
should be working from the CVS.
> External Documentation
Again, absolutely necessary. But NOT to hold up the release.
> 1) Migrate all Composable to Serviceable
Makes me a bit nervous, as it seems to be a significant change, but I
haven't had time to look at the code revisions, and you have. What gains do
we get other from it other than cleaner code and the fact that Andrei also
removed the dependency on TimeScheduler? What effect on defects, stability,
performance, footprint?
> 3) Change code so that it doesn't use the TimeScheduler
Either that (e.g., a resetable watchdog thread per service thread), or write
a TimeScheduler class that is more space efficient for our needs. Moot
point if #1 (previous paragraph) gets done, since it is included in that set
of changes.
Bottom line is simply that 2.1 is advanced far enough that I think we should
be just focusing on making sure that it is stable. Anything that doesn't
contribute directly to stability can be deferred to post-2.1, in my opinion.
As soon as we are done with 2.1, I think it is a high priority to add
attributes to mail and user objects (and repositories). A lot of work is
being hindered by their lack.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
