Ives, > I've considered this and may end up going this route, but it's not a > long-term solution since the product direction may easily change and the > solution rebuilt.
I doubt that Ipswitch would dare make drastic changes to ODBCUSER.DLL requirements, since there are thousands of people using customized versions, but it's true that you're unlikely to get them to sign a contract. > Don't get me wrong, I certainly appreciate the advice either in recent > postings or throughout the entire archive. You are a large contibutor to > this forum and I think everyone here values your contributions. Thanks, and welcome to active duty on the Forum yourself! > I was more hoping to convey that this should be a specific > development target for Ipswitch. Not just an off-shoot possibility > by modifying DLL's intended for ODBC calls. Working at a systems > integration company has taught me that writing the internals of the > application to support ODBC will yield tweaks geared specifically > towards ODBC usage and performance. While I'd agree with you in theory, there's nothing particularly tweaked about Imail's native ODBCUSER.DLL: it exports necessary functions, then uses E-SQL to execute queries; it could just as easily bind to an LDAP library, with no loss in performance. The lack of publicity for IMail's pluggable authentication mechanism is probably due the opacity of C/C++ to the average sysadmin, and in turn no one has stepped up to make the necessary modifications. Another prohibitive factor is the "ODBC" in the filename; it has been a complaint of mine for some time that the shipping ODBCUSER.DLL doesn't use OLE DB, which (a) is significantly faster for connectivity to standard SQL back ends, if providers are available, (b) would easily allow for the use of MS' OLE DB connectivity to AD (which is, however, read-only) without a separate LDAP port, (c) is the state of the art on Win32, and (d) with ADO, is implicitly store-agnostic, meaning that, while ANSI SQL is still the most common query language, the ADO framework could very easily be used to query other data stores with their own application semantics. Another thing to keep in mind is that SQL, a set-centric query language, is not at its best when performing the singleton SELECTs that are its major duty under IMail. Simpler, indexed hierarchical data stores like the Imail Registry, the NT SAM, and LDAP are always going to be better for such functions. But the SQL handicap is only present as long as you leave it in your ODBCUSER.DLL code. I think everything's there already to build what you're describing, it's just obfuscated by the "ODBC" moniker. Ipswitch could spend just a little time making cosmetic changes and some third-party products might pop up right away. -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/
