Re: more url-utils?

[Ted Zlatanov]

On Wed, 18 May 2011 19:05:57 -0300 Stefan Monnier <address@hidden> wrote: 

SM> But your `body' is nothing more than the body of the callback if
SM> passed as a lambda (and indeed within the macro you'll have to wrap
SM> `body' with a `lambda' to use it in the process-sentinel), so
SM> providing both `callback' and `body' arguments is not very useful.

I thought it was more readable to cradle statements in a "with-xyz"
macro (e.g. `with-temp-file', `with-parsed-tramp-file-name') than to
craft a lambda for a callback.  It's not a big deal, I can write the
macro on top of `url-fetch' anyhow.

>> (defun* url-fetch
>> (url &rest spec
>> &key silent callback request-data request-method
>> request-extra-headers standalone-mode gateway-unplugged
>> honor-stylesheets confirmation-func cookie-multiple-line
>> cookie-storage cookie-confirmation cookie-secure-storage
>> cookie-secure-confirmation
>> &allow-other-keys)
>> ...)

SM> I'm not sure all those args make sense, but yes, that sounds
SM> about right.  We should think hard about what those args should be,
SM> within the larger context of URL rather than only http.

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

SM> No, callback just makes it possible to do the request asynchronously,
SM> but it can still be performed synchronously and for some URLs we may not
SM> know how to perform them asynchronously (as the docstring of
SM> url-retrieve already explains).

OK.

>> In the asynchronous mode we could return a lambda (see that? I used a
>> lambda!) that can be evaluated to wait until CALLBACK completes and then
SM>                        ^^^^^^^^^
SM>                         called

>> returns whatever CALLBACK returned.

SM> That's a good idea.  Kind of like a future.

All right, I'll provide that.  Are you OK with the defun* approach and
having each `url-{http,ftp,etc}-fetch' function build on the base
`url-fetch'?

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).
There will be a lot more function parameters on the stack, though--I
don't know if that's a problem.

Ted