Does anyone have any objection to dropping the unitized interface for
`net/url'? Specifically, did anyone ever used it for any purpose
other than making up an `ssl:*' variant of the library?
I'm looking into making it deal properly with ssl connections, and I
think that the right way to do it is by making the code dispatch to
the plain tcp functions or the ssl versions based on the scheme of the
input url.
1. Looking at the code, there are only two tcp functions used
(`tcp-connect' and `tcp-abandon-port'), so eliminating the unit
interface and just hooking things up so that an "https" scheme uses
the ssl functions is relatively easy.
2. Another possibly solution is to make the `net/url-unit' import two
tcp units, one for plain connections and one for https connextions.
The problem with that is that it still breaks compatibility since
the imports are different.
3. Yet another solution is to make it do the same thing it does now,
but for "https" urls it will always use the ssl bindings. This
means that you can still parameterize the code over the tcp
functions, but "https" urls bypass that parameterization and use
the ssl things directly.
I dislike #2 since it's making things even more hairy in the unit
sense, and I don't think that that's a good direction. I dislike #3
since it feels like a bad hack.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
