[racket-dev] net/url and https

+1 to that sentiment.

I think this whole conversation is meant to be about how do we best
get from here to there. The question pending is how much is it
reasonable to break code that might use more obscure parts of the
current api. I'm taking the relatively hard-line stance that we should
not break any of it (even without really knowing how much of it
exists), partly just because I think preserving backwards
compatibility (esp. for core libraries) is important and partly
because there is not yet a authoritative response of the form "well,
please just go use this well-designed library instead" available yet.

Robby

On Mon, Jun 20, 2011 at 9:52 AM, Eric Hanchrow <eric.hanchrow at gmail.com> wrote:
> On Sun, Jun 19, 2011 at 3:47 PM, Eli Barzilay <eli at 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