On Sun, Jun 19, 2011 at 3:47 PM, Eli Barzilay <e...@barzilay.org> wrote: > Two minutes ago, Neil Van Dyke wrote: >> >> I also think that Eli's option #1 could be done without breaking >> backward-compatibility, but I'm not sure it's worth the effort in >> code and documentation, and I don't want to discourage him moving >> forward with #1 by making the task harder than it has to be. > > Heh, I just thought about a way to do that, which is likely what > you're thinking of: > > * `net/url-unit' and `net/url-sig' stay the same. Code that uses > them works as before. > > * `net/url' becomes the (non-unit, of course) library that does > dispatching over "https" with an ssl connection. > > This might work, but would be very odd. Specifically, the description > of `net/url-unit' will need to mumble something about creating a > result that is *not* like `net/url' in that there is no such dispatch. > > Backwards compatible, but IMO very ugly. But perhaps it's worth it?
I don't have a strong opinion about which option is best. I don't have much code that deals with URLs at all (and let's be blunt; it's _all_ hobby code). And I don't understand units enough to comment on anything involving them. I do feel strongly that Racket should have a way to deal with https reasonably painlessly. I also think that Eli is right about the awkwardness of the current interface -- in order to get the status code from the response, I have to parse the headers myself, which seems silly. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev