Re: DBmail webmail app

On 6/6/2007 Tom Allison (tomtacocat.net) wrote:
> I really like dbmail.  But I'm not a large scale
environment.  I 
> don't have a dual core anything.  I currently have only
four 
> accounts.  But for these four accounts it is one of the
best 
> performing applications I've used, and I've tested a
lot of them.  
> I'm just asking that we keep in mind that while 100MB
might be 
> something to keep in consideration going forward, don't
lose the 
> sight of the smaller users for your sake.

SiS could always simply be a config option... so if you
don't want the 
overhead, don't enable it...

-- 

Best regards,

Charles
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Charles Marcus wrote:
> 
> SiS could always simply be a config option... so if you
don't want the
> overhead, don't enable it...

Better yet: don't add the new tables (when I publish them)
and dbmail will
gracefully downgrade to the old/current behaviour.

-- 
 
____________________________________________________________
____
  Paul Stevens                                      paul at
nfg.nl
  NET FACILITIES GROUP                     GPG/PGP:
1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

On Wed, Jun 6, 2007, Paul J Stevens <paulnfg.nl> said:

> Charles Marcus wrote:
>> 
>> SiS could always simply be a config option... so if
you don't want the
>> overhead, don't enable it...
> 
> Better yet: don't add the new tables (when I publish
them) and dbmail will
> gracefully downgrade to the old/current behaviour.

But let's avoid parallel code paths and database schemas
wherever
possible. 

Aaron
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

>>> SiS could always simply be a config option...
so if you don't want the
>>> overhead, don't enable it...

>> Better yet: don't add the new tables (when I
publish them) and dbmail will
>> gracefully downgrade to the old/current behaviour.

> But let's avoid parallel code paths and database
schemas wherever
> possible. 

Agreed - wouldn't this also complicate things if you decided
to enable 
this functionality? Also - even if SiS isn't enabled, once
this 
functionality was implemented, messages would still be
stored by their 
different mime parts, so the new tables would still be
needed?

-- 

Best regards,

Charles
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Aaron Stone wrote:
> On Wed, Jun 6, 2007, Paul J Stevens <paulnfg.nl> said:
> 
>> Charles Marcus wrote:
>>> SiS could always simply be a config option...
so if you don't want the
>>> overhead, don't enable it...
>> Better yet: don't add the new tables (when I
publish them) and dbmail will
>> gracefully downgrade to the old/current behaviour.
> 
> But let's avoid parallel code paths and database
schemas wherever
> possible. 

There's this weird word called deprecation. There's actually
very low
cost in maintaining the current message handling code for
the time
being. Mark it as such, and leave it be. It's well
isolated.

-- 
 
____________________________________________________________
____
  Paul Stevens                                      paul at
nfg.nl
  NET FACILITIES GROUP                     GPG/PGP:
1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

On Wed, Jun 6, 2007, Paul J Stevens <paulnfg.nl> said:

> Aaron Stone wrote:
>> On Wed, Jun 6, 2007, Paul J Stevens <paulnfg.nl> said:
>> 
>>> Charles Marcus wrote:
>>>> SiS could always simply be a config
option... so if you don't want the
>>>> overhead, don't enable it...
>>> Better yet: don't add the new tables (when I
publish them) and dbmail will
>>> gracefully downgrade to the old/current
behaviour.
>> 
>> But let's avoid parallel code paths and database
schemas wherever
>> possible. 
> 
> There's this weird word called deprecation. There's
actually very low
> cost in maintaining the current message handling code
for the time
> being. Mark it as such, and leave it be. It's well
isolated.

Yes, exactly, the cost is low *for the time being*. We need
to transition
to whatever new stuff we're going to do so that we can drop
the old code
after a major release or two. The cost to maintain it will
increase as it
becomes unused, and the likelihood of bit rot will be very
high.

>From a quick look at the SVN log, the auto_replies code
was broken for 15
months. The responsible thing for me to do last month was
probably not to
fix the segfault that was reported, but to throw the code
out entirely!

I would be satisfied with an ERROR level message that
logged, every time
the daemon starts, "You are running DBMail version 2.4
using the 2.2
schema. You must the upgrade script as this schema will not
be supported
in the future."

Aaron
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail