Just a rough estimate would be fine, but how much would the DLL + documentation cost? Would there be any support? This is just a rough estimate from our side as well, but we would probably spend about $100 per server or $500 for an unlimited usage C++ COM DLL that works with MS SQL 2K/Registry. We would need documented methods and properties that allows us to add/edit/delete every stored value.
As for support, as long as the documentation provides test code for enough scenarios and there are no install problems, we won't need any. Also, the Forum could probably provide enough "support" beyond that. Oh yeah, and some short trial-period would be nice for benchmark and testing. As a bonus, we would probably spend more (much more) if the components also allowed for the reading and sending of mail. For example, a collection (or recordset) of messages, a shaped recordset of folders, things like objMail.emptyRecycleBin, objMail.ReplyToAll.SendTo, objMail.ReplyToAll.OldMessage, objMail.NewMessage.Encoding, and objMail.NewMessage.Importance. Or if you're going the open source route, I'll add some of the components I've finished so far (VB, not C++). Not many yet, but every little bit helps. We might want to check if IPSwitch is either working on that already or if they have a problem with the reverse engineering of their data store. Thanks, Norm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sanford Whiteman Sent: Tuesday, March 19, 2002 2:06 PM To: [EMAIL PROTECTED] Subject: [IMail Forum] Poll re: Interest in SQL/Registry hybrid solution All, Recent threads re: Imail's database options have surfaced the concept of a hybrid solution that combines the best of the Registry with the best of SQL. Targeted benchmarks and empirical evidence suggest that the Registry is faster by 10x or more; on the other hand, only with SQL support can true accounting, auditing, and integration take place. So our proposal is for a synchronization technology that, through two-phase commit, can preserve the speed of in-memory local storage for OLTP and the openness of SQL queries for OLAP and general administration. We already have proof-of-concept through DLLs we whipped together last week. The first release of such technology would only support MSSQL/MSDE on the SQL side; bridging the same gap with MySQL on *nix has significant obstacles, so we'd put that off until sufficient results are in from the Win32 release. So, while our guess is that anything that speeds up Imail would be useful to systems already under stress, I'm reaching out to the list to see if there is sufficient interest out there to continue coding toward a full-fledged product. Anybody with a question or personal viewpoint on this, please speak up. Thanks and regards, Sandy ___| Sanford Whiteman, Chief Technologist ___| Broadleaf Systems + Support, Inc. ___| mailto:[EMAIL PROTECTED] 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/ 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/
