On 6/14/07, David Roundy <[EMAIL PROTECTED]> wrote:
No problem! But less code is scary. I'd rather at least let one darcs stable release have both interfaces, and probably would prefer to keep the libcurl option open until the HTTP module is packaged in debian stable.
Thinking this over, the Network.HTTP implementation offers one potentially nice improvement - performance. Otherwise, libcurl really does everything needed*. Eric previously pointed me to a ticket ( #377 ) which involved quite a few issues, but one of them was performance on large repositories. Would a patch that showed HTTP download improvement and leaves the libcurl dependency alone be more acceptable? It sounds like Tim has made some progress in the area, but maybe I can do some myself? I'll make sure the HTTP module is optional and libcurl will remain the fallback for http/s requests when it is not present.
Does HTTP do ssl connections, by the way?
Pretty sure it does, but haven't tested. Any servers you could suggest? Justin * I realized my initial motivation, the NTLM authenticating proxy at my workplace, was incorrect - libcurl knows how to interact with it just fine. _______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
