<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>