15 minutes ago, Robby Findler wrote:
> I think we should not remove anything from the net/url library
> (including the unitized interface) as I believe that will break old
> code.
This means one of 2.5 new options:
4. Create a new library that will do exactly what `net/url' is
doing, except without the unit interface (or the two-tcp-imports
interface), and with the desired dispatching over "https" urls.
5. Create a new library that will do the right thing, extending what
net/url does by a whole bunch of stuff. That means a complete
redesign of the library.
6. Do #4 first, then do #5.
I think that #5 is inevitable. The `net/url' is designed in a way
that dooms it to be a toy. For example, it just gives you the
contents, possibly with the HTTP reply headers pretty much as is --
which means that there is no way to distinguish a 404 result (should
result in an error) or a 301 result (should follow the redirection).
To properly deal with these things, you currently need to manually
look at the impure port and parse it yourself. Further, there's a
bunch of additional functionality that is missing from it.
I do plan to write it (a new library, the #5 option). Of course
unless someone else does that (*wink* *wink* *nudge* *nudge*). It
might even be compatible with the current `net/url', but probably not
with the unit part.
Given that there is a need for such a library, #4 is not a viable
option. However, doing this will require more time. (Specifically, I
can change the `net/url' as previously described right now, but a new
library will probably take much more time.) This leaves #6 as the only
other alternative if there's a need to get a solution right now. But
I dislike it, since I consider `net/url' a toy in terms of
functionality, and #6 means duplicating that toy only to solve a
problem temporarily.
> On Mon, Jun 20, 2011 at 5:57 AM, Eli Barzilay <e...@barzilay.org> wrote:
> > 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
> >
--
((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
