Re: url-cache - (require 'url)

[Mark Plaksin <happy@mcplaksin.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Maybe there's a better approach to the problem I'm trying to solve.  I want
>>>> to add support for ETags to nnrss in Gnus.  To do that, nnrss needs access
>>>> to HTTP headers.  nnrss currently uses mm-url-insert which calls
>>>> url-insert-file-contents.  Those seem like the right functions to use but
>>>> they don't provide access to the HTTP headers.
>>> 
>>> Why do they seem better to you than url-retrieve (or even url-http) given
>>> the fact that they do not give you the info you need?
>
>> Because url-insert-file-contents does some coding-system things that I
>> assume are important for inserting URLs into buffers.  I don't know
>> anything about coding-systems.  I could write a new function that uses
>> url-retrieve or url-http but I'd probably have to duplicate the
>> coding-system parts which seems wasteful.
>
>> It also seems that other applications that want to insert the contents of a
>> URL could benefit from having access to HTTP headers.
>
> Good point.
>
> I guess a good answer to that is simply to make url-insert-file-contents
> "trivial" by moving most of its contents to a separate function.
> Say url-insert, as in the patch below.  Does that provide the functionality
> you're looking for?

(Sorry for the huge delay.  Busy life.)

This looks good to me.  The idea being that any application which needs
access to HTTP headers should call url-retrieve{,-synchronously} and then
use url-insert if it wants to insert the body in a buffer, right?

Thanks!