Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=78075 --- shadow/78075 2006-05-02 18:29:28.000000000 -0400 +++ shadow/78075.tmp.26998 2006-05-02 23:08:41.000000000 -0400 @@ -532,6 +532,29 @@ managed implementations, which inherits a lot of advantages but (even if they can get better) will *never* compare, performance wise, to hand-optimized assembly implementations as used in openssl, gnutls... In fact using a well known managed AES implementation (from a Mono competitor in the Windows world) would still be much slower than wget (sorry the competitor's EULA prohibits publishing benchmarks). + +------- Additional Comments From [EMAIL PROTECTED] 2006-05-02 23:08 ------- +Hello, + +Am not sure there is much that we can do here at this point. If the +setup does not allow for the fast https transfers as described +originally due to the encryption used let me recommend that folks use +System.Diagnostics.Process.Start ("wget http://url"). + +The constraints on us are: +* It is too late for us to make changes to the crypto stack for CODE +10 (the crypto deadline was sometime in January). +* There is no way we can complete and then backport any of the JIT +optimizations that might get 10-15% of improvement in the best case in +time for you to ship. +* There is no way we can bind OpenSSL and use it in our stack in the +short-term. + +If the ZLM server can not downgrade the cryptographic algorithm on the +server, then my suggestion is to use wget as described before. + +Btw, am confused about wget and libssl, because I could swear those +licenses were incompatible. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
