On Nov 11, 2011, at 4:20 PM, MM John wrote:

The backwards compatibility issue is easily solved by dupllcating, renaming and archiving all the old files including the database Then they wouldn't be deleted or overwritten and could be reinstated Should have thought of that when I wrote it

Here's the scenario I'm talking about: You archive the old install and install the new version An upgrade from version 2 of Dada Mail to version 4 of Dada Mail is going to require some migration steps - the internal format of the data that makes up a mailing list has changed Maybe you want to move from the plaintext backend, to an SQL backend, since there's some fancy features you want to take advantage of You use the new version for a few days and decide that you want to switch back Uh-oh, all your data is in the new format and in that few days, a few messages have been sent out, archived, maybe a list has been created and a bunch of subscribers have subscribed, unsubscribed, etc

There's no way to bring that history back to your 2 x release You can just use the backup you made, but that backup is now out of date What happens, if a subscriber that removed themselves, suddenly finds themselves back on the list and receiving messages? That's a big problem

I don't understand the below sentence

It's pretty hard to know what your deliverability is actually with Dada Mail 2x Do you have any idea (meaning: data)?

Do you have any data on how many people may be getting your messages that are being sent? Message opens, clickthroughs, bounces - any sort of metrics like that? I would have thought the newest revision of the Tracker plugin would be a killer feature for you Dada 4 x has a lot more feedback on what's going on with your list than Dada 2 x

Since speed is a such high priority for me, I don't see that I'll invest the time to test it 11 hours for one mailing would not work for me, not when I can send it in one hour with a perfectly workable program

I'd just double-check it's working As the guy who clobbered the code together, I think you're crazy to use such an old copy of the program :)

But, I do think speed isn't the first and last point to think about, when it comes to sending Perhaps deliverability is also important You can send as fast as you'd like, but if no one is receiving the message, what's the point of sending the message out at all?

My last batch of optimizations are getting around 5 messages/sec on the profiler That's pretty freakin' fast

But I'll keep lurking on this list, maybe something will change

Sponsor the feature of, "lightning quick sending" Honestly, it'll turn my attention to the feature in a heartbeat :)