Use quri instead of puri for URIs.

[tmccombs]

Second attempt at this. Fixed several bugs from the first attempt at using quri.

[tmccombs]

Hunchentoot successfully compiles with this. If you still think I should build a compatibility layer, let me know.

[hanshuebner]

The issue is not so much Hunchentoot, but existing libraries and applications that try to pass PURI:URI instances as argument or that rely on a PURI:URI instance to be returned from HTTP-REQUEST. The former is relatively easy to fix, but fixing the latter would mean that that by default, a PURI:URI would be returned and only if the user specifically requests it - maybe by the way of setting a special variable or feature or keyword argument, a QURI:URI would be returned instead.

Zach Beane ran the Quicklisp dist creation process with the previous version of your change ( http://report.quicklisp.org/2015-07-10/failure-report.html) and found that to cause many errors because many libraries depended on DRAKMA pulling PURI as a dependency. I have not investigated how these failing libraries use PURI, but it is probably safe to say that they'd need one of the two suggested compatibility changes above to continue working.

-Hans

2015-07-11 23:14 GMT+02:00 Thayne McCombs [email protected]:

Hunchentoot successfully compiles with this. If you still think I should build a compatibility layer, let me know.

— Reply to this email directly or view it on GitHub https://github.com/edicl/drakma/pull/65#issuecomment-120662013.

[tmccombs]

Ok, I'll add the compatibility. Do you know which libraries require puri support?

[hanshuebner]

2015-07-12 16:49 GMT+02:00 Thayne McCombs [email protected]:

Ok, I'll add the compatibility. Do you know which libraries require puri support?

I only have the error output that Xach sent. I would propose that DRAKMA returns a PURI:URI unless the caller explicitly requests a QURI:URI.