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

Reply via email to