> The biggest problem with the registry is that it is basically an > opaque binary file structure that if (when) it gets corrupted is > almost irretrievable.
It's irretrievable if people don't have a backup. If people don't run backups, they shouldn't run mailservers. The claim that there's anything uncomfortably "opaque" about the Registry is absurd, as this could just as well be levied at any RDBMS data stores that provide full backup, restore, and ASCII export APIs, but which are not intended to be accessed out-of-band in a hex editor--a standard scenario across the board of data stores. > Imail doesn't know spit about views or use any decent structure, so > we have to trick it into thinking the views it's seeing are tables. > Problem is, updating a view is mighty tricky. We've never had any trouble extending IMail to use any combination of tables and views for a multi-hosting environment, and we've created SQL-based architectures that would make your head spin. I don't know what you've tried, but you must have barked up some pretty crazy trees for XML to seem like the future! SW>> Or an XML file vs. a distributed LDAP directory serving up a SW>> corporate userbase from RAM. > Yes, more efficient than XML but can/are all parameters stored in the > directory? Immaterial. The point is the _userbase_, which will take the giant brunt of the traffic on any mailserver vs. the domainbase. The new wonder-product offers no substantive advantange in domainbase management, and a marked disadvantage in userbase management. Now, if the wonder-product were to access the domainbase via LDAP or ODBC _in addition to_ accessing the userbase the same way, that would be something to talk about, and a clear advantage over IMail. > No, just userbase which then must be matched to other configuration > parameters and managed separately. Better than the least-common-denominator offered by the product in question. SW>> syncing to an RDBMS or other directory is not flexibility. > Web services make it extremely flexible, just not easy. I'll say it again: being _forced_ to manually synchronize database information between disparate back ends is not "flexibility." Flexibility is when you can have data served up from industry-standard back ends, _or_ you can optionally sync it up manually from a local store if you have some desire to do so. There's no question to an application architect that what they are offering as a world-beating "open system" is just immature: if a plug-in option even existed that offered, at some point in the future or via third parties, ODBC or LDAP userbases, that would be a step in the right direction, but from what you've written that isn't the case. SW>> The recent claims that IMail functionality is "behind the times" are SW>> provable in almost every case, but completely fail when it comes to SW>> userbase management. > Ever restored and Imail registry key from one server to another then > had to edit the whole thing manually? Disagree on this one. Yup, I've restored IMail domainbases many, many times. Never batted an eye. I'm sure glad I don't have to open an XML editor, too, if I need to merge domainbases, let alone an IDE. Hey, this wonder-product is kewl, it's exciting, but it's self-evident that its developers appear to have chosen the web service buzzword over deeper attention to the way userbases and databases are used by extremely knowledgeable mail admins cross-globe and cross-platform. It's fruitless to pretend that, say, pam_ldap and pam_mysql on *nix are just backward and what they really need is a good SOAP API to a local file. Try that on the Postfix list if you need some heat. :) --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.mailmage.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.mailmage.com/products/software/freeutils/exchange2aliases/download/release/ http://www.mailmage.com/products/software/freeutils/ldap2aliases/download/release/ --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
