<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div><div>And some of us have been relying on Vincent's tis package for our production code and would very much like to see it in the platform.</div></div><div><br></div><div>And surely we do need a cross-platform solution.</div><div><br></div><div>Chris</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>><br><span style="font-weight:bold">Date: </span> Monday, 4 November 2013 06:55<br><span style="font-weight:bold">To: </span> Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>><br><span style="font-weight:bold">Cc: </span> Haskell-Cafe <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [Haskell-cafe] SSL support for hackage and cabal<br></div><div><br></div><div dir="ltr">FWIW, I went through this exact decision making process about 2 years ago when working on TLS support in http-conduit[1] and came to the conclusion that the best choice by far was using Vincent's tls package. I've been very happy with the results. Not only is Yesod used on a number of platforms, but I've shipped commercial software to both Windows and Mac, and having one less system library to worry about saved me lots of pain[2].<div><br></div><div>[1] Actually, the only reason I ever wrote http-conduit instead of just using HTTP was that I needed TLS support for OpenID, and I could never get the existing TLS-in-HTTP-package solutions to work.</div><div>
[2] An example to the contrary to text-icu, which to this day I cannot reliably get installed on a Windows system.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 8:39 AM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">agreed, would likely be a portability nightmare, and the cabal devs have enough on their plate as is!</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 1:35 AM, Vincent Hanquez <span dir="ltr"><<a href="mailto:tab@snarc.org" target="_blank">tab@snarc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 2013-11-04 01:02, Donn Cave wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How strongly do you feel about the cross platform and dependency issues?<br></blockquote></div>
Quite ? I think that would be rather bad to have cabal have ssl on unix, but<br>
not on MacOSX and Windows.<div><br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When I needed SSL encryption, I whipped up a little module with foreign<br>
calls to OpenSSL. For an ordinary client, which is all I use it for any<br>
more, it's a simple interface -- init, connect, read, write, a couple<br>
error functions. I have to link -lssl -lcrypto. The great thing about<br>
this is, not only do I have a high degree of confidence in the implementation,<br>
I don't expect it to _ever_ change in a way that will inconvenience me.<br>
If my application ever needs to work on a platform with a different SSL,<br>
just need a new module with init/connect/write etc.<br><br>
Does that seem like a possibility, just write minimal interfaces to<br>
existing platform standard SSL implementations, and move on to more<br>
interesting problems? Or is this really an area with interesting problems<br>
of its own that I'm missing?<br><br></blockquote></div>
I think that's the best alternative (provided wide spread non support for tls),<br>
except there's no platform standards (think about chromium, and mozilla<br>
cases for a very similar problem), and it's probably going to be "interesting"<br>
to maintain (as in it take probably quite a bit of resource for browsers to keep on top).<br><br>
--<br>
Vincent<div><div><br>
______________________________<u></u>_________________<br>
Haskell-Cafe mailing list<br><a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a><br></div></div></blockquote></div><br></div></div></div><br>_______________________________________________<br>
Haskell-Cafe mailing list<br><a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br><br></blockquote></div><br></div>
_______________________________________________
Haskell-Cafe mailing list
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a>
</span></body></html>