Aaron Stone wrote:
Matthew T. O'Connor <matthew@zeut.net> said:
I would like to add one additional safeguard. That is add an
enable_is_header variable in dbmail.conf that defaults to false. This
requires that the mail admin knowingly turn this feature on knowing that
his database is uptodate.
This is a neat idea in concept, but I'm worried that we would end up with
an unwieldy proliferation of such settings.
Not really. These types of variables would only exist in the 2.0.x
branch, they would not exist in head, so once 2.2 is release they would
go away.
DBMail 2.0 branch is supposed to be stable, I should be able to upgrade
from 2.0.0 -> 2.0.1 -> 2.0.x without having to think, or having to do
anything special.
People should be running dbmail-util on a regular basis, and as long as
they run dbmail-util to do the is_header updates before running 2.0.2,
everything should be fine.
They should be, but they may not be. DBMail will hum along just fine
without ever running dbmail-util. In someone might never want to delete
messages from their database so they may not use it at all. These
people would get bitten.
You bring up a good point, which I agree with, that there should be
nothing special happening as we move upwards in 2.0.x, but is_header is
going to be a big help and I think that one revision of explaining that
dbmail-util should be in one's regular routine is worth the hassle.
I have felt for quite a while that this project doesn't pay enough
attention to these types of things. If you want to be considered a
serious IMAP server then users can't think that features get added under
their feet inside of a stable release.
My original complaint was that it should be OK to upgrade and downgrade
freely along 2.0.x, and I still hold by that, except that I think the
dbmail-util solution is a reasonable compromise.
I still disagree, but that is just my 2 cents :-)
Matthew
