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.

And surely we do need a cross-platform solution.

Chris

From: Michael Snoyman <michael@snoyman.com>
Date: Monday, 4 November 2013 06:55
To: Carter Schonwald <carter.schonwald@gmail.com>
Cc: Haskell-Cafe <haskell-cafe@haskell.org>
Subject: Re: [Haskell-cafe] SSL support for hackage and cabal

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

[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.
[2] An example to the contrary to text-icu, which to this day I cannot reliably get installed on a Windows system.


On Mon, Nov 4, 2013 at 8:39 AM, Carter Schonwald <carter.schonwald@gmail.com> wrote:
agreed, would likely be a portability nightmare, and the cabal devs have enough on their plate as is!


On Mon, Nov 4, 2013 at 1:35 AM, Vincent Hanquez <tab@snarc.org> wrote:
On 2013-11-04 01:02, Donn Cave wrote:
How strongly do you feel about the cross platform and dependency issues?
Quite ? I think that would be rather bad to have cabal have ssl on unix, but
not on MacOSX and Windows.


When I needed SSL encryption, I whipped up a little module with foreign
calls to OpenSSL.  For an ordinary client, which is all I use it for any
more, it's a simple interface -- init, connect, read, write, a couple
error functions.  I have to link -lssl -lcrypto.  The great thing about
this is, not only do I have a high degree of confidence in the implementation,
I don't expect it to _ever_ change in a way that will inconvenience me.
If my application ever needs to work on a platform with a different SSL,
just need a new module with init/connect/write etc.

Does that seem like a possibility, just write minimal interfaces to
existing platform standard SSL implementations, and move on to more
interesting problems?  Or is this really an area with interesting problems
of its own that I'm missing?

I think that's the best alternative (provided wide spread non support for tls),
except there's no platform standards (think about chromium, and mozilla
cases for a very similar problem), and it's probably going to be "interesting"
to maintain (as in it take probably quite a bit of resource for browsers to keep on top).

--
Vincent

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe