Re: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?]

["T.V Raman" <raman@google.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1440 bytes --]

Daniel Brooks <db48x@db48x.net> writes:

1+ on libcurl, this discussion happened a while ago here though and ran
aground, dont remember why.
But independent of the ability down the road to native-compile elisp, I
still think re-using the work of the curl project to get an HTTP library
that the emacs project doesn't have to maintain would be a big win

> Adam Porter <adam@alphapapa.net> writes:
>
>> Of course, it would be ideal if Emacs had a built-in HTTP library that
>> didn't require an external dependency like Curl, but Curl does work
>> well.  The only issue I have with it is that certain data can only be
>> passed via either the command line (leaving it visible to the whole
>> system) or temporary files (which have to be carefully handled), which
>> is a concern for, e.g. cookies, authentication tokens, passwords, etc.
>> Unfortunately, when that issue was raised and a solution proposed in
>> 2003, it was quickly rejected.[8]
>>
>> 8: https://curl.se/mail/archive-2003-08/0099.html
>
> For a built-in library, it would be better to use libcurl. This ensures
> that there won't be any complications from hiding this type of
> information, and the curl command-line program is just a simple wrapper
> around libcurl anyway. In fact, even an installable library could
> include libcurl in a dynamically-loadable module.
>
> db48x
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8