Re: more url-utils?

[Ted Zlatanov]

On Wed, 18 May 2011 23:28:41 -0300 Stefan Monnier <address@hidden> wrote: 

>> All right, I'll provide that.  Are you OK with the defun* approach and

SM> Sure.

OK, it's on my TODO list.

>> Also I think the callback should get the status and then &rest plist.
>> The plist will depend on the URL protocol but there will be common keys
>> to determine the protocol, if there were headers, etc.  That's a little
>> bit less functional but the data will not be hidden in buffer-local
>> variables like it is now (although those will still be available).

SM> I think it's OK to use buffer-local vars to keep things like
SM> url-header-alist.
SM> [...]
SM> wait, it's OK to use buffer-local vars in a buffer created for the
SM> occasion (as in url-retrieve) but indeed if url-fetch stores the result
SM> in the current buffer as I suggested, then it's ugly to modify the
SM> buffer's local vars as a side-effect and it's better to pass it as an
SM> argument to the callback.

Right, `url-fetch' no longer implies `with-temp-buffer'.

>> There will be a lot more function parameters on the stack, though--I
>> don't know if that's a problem.

SM> It's not a problem but I'd much prefer an "alist" than a "&rest
SM> plist".

OK.  But if the status is nil we couldn't get any data so there are no
URL properties.  So we can have just one callback parameter "url-info"
which is nil if the request failed and an alist if it worked.

How would the callback find out what actually failed?  Does it even need
to?  I think it's enough to know the request failed, the user can look
in *Messages* to find out.

Ted