Re: more url-utils?

[Stefan Monnier]

> Yeah.  So perhaps we simply write `url-http-fetch' that specifies the
> base `url-fetch' props and then adds its own list on top.

Hmm... maybe that's the right approach, indeed, but I wouldn't know
(for lack of experience).

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

Sure.

> having each `url-{http,ftp,etc}-fetch' function build on the base
> `url-fetch'?

It doesn't sound too bad, tho maybe I'd have expected that url-fetch calls
one of url-<transport>-fetch, rather than the other way around.

> 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).

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

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

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


        Stefan