Len, > I'm hoping somebody comes up with some scripts to slave Imail the >SQL database, rather than vice versa. ie, you >create/modify/delete...in the SQL database, and that triggers scripts >to sync Imail's registry database of domains/users, so Imail doesn't >get slowed down horribly by using the SQL database.
I have never disliked your idea, but it has major logical flaws. I have proof-of-concept xprocs for SQL that can replicate the data to a remote Imail server's Registry. But for Imail to use the Registry for authentication, the domain in question must be set as a Registry domain (obviously). This is fine for simple authentication tasks such as necessary for POP3/SMTP, and even some of Web Messaging's functionality. But the moment users manage certain account settings using the normal WM interface, the setting will be changed in the Registry and will not be propagated back to the database. Presto--the connection is broken. And hooking the Registry API is not within the realm of reason, trust me. There are two possible solutions. First is to remove the links from Web Messaging for any setting that would get stored in the registry, and build an "advanced management interface" in ASP/Perl for such settings that goes through the back-end DB first to ensure two-phase commit. The second solution is to remove the orphanable settings from the primary domain's WM, as above--or maybe remove all settings for clarity--and then assign each domain a second, overlapping domain with the same top directory, and a hostname like my.domain.com, but this one hits the ODBC DSN; the second, slower, domain is used only for setting account options, and the speedier "caching-only" domain is used for SMTP AUTH and normal mail reading and composition. Your idea does have significant technical hurdles as well, even with just unidirectional replication, but I think I can get around them. If enough people write back who are interested in seeing this architecture, even with the above caveats, I will continue toward productizing it. >Clearly, this the only way to scale Imail seriously. It is *a* way, but it is certainly not the only way. There are plenty of things that Ipswitch could do to improve the efficiency of their SQL calls--like I've said so many times, using the native SQL API (OLEDB) rather than a flatly outdated DSN-ful ODBC call will be significantly faster; removing the reliance on the external ODBCUSER.DLL (by embedding the logic right in the code for basic connectivity) would also be better. And admins are not without responsibility for SQL performance. I don't think it's necessary for the application to treat DBAs with kid gloves regarding performance tuning (though it would be much better if the docs even mentioned such things). Did you know that using a covered index on username and password can give 200x better performance? Well, if you don't, you can bet that most admins that just roll out Imail against SQL don't know it either. Just because you might only have to maintain a few tables in a single DB doesn't mean you (or your employer) shouldn't appreciate that you have to at least "minor" as a DBA. In a related example, there's been tons of bellyaching here about not being able to restrict user count in an external DB. Well, in 90 seconds, I wrote T-SQL that does that exact thing (posted earlier this week). If one doesn't do that kind of due diligence, how can one even begin to complain about SQL not being fast enough or (much more ridiculous) open enough? Sandy Please visit http://www.ipswitch.com/support/mailing-lists.html to be removed from this list. An Archive of this list is available at: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Please visit the Knowledge Base for answers to frequently asked questions: http://www.ipswitch.com/support/IMail/
