Re: more url-utils?

[Stefan Monnier <monnier@iro.umontreal.ca>]

SM> I think you're just afraid of lambda ;-0
> ...or are you afraid of macros? ;)

That's partly true.  But your `body' is nothing more than the body of
the callback if passed as a lambda (and indeed within the macro you'll
have to wrap `body' with a `lambda' to use it in the process-sentinel),
so providing both `callback' and `body' arguments is not very useful.
And of course `callback' has the advantage that it takes an argument
(which will of course be `status') whereas `body' doesn't have such an
easy and obvious access to the status.

SM> But I also like the idea of passing url-request-method and such as
SM> explicit arguments.

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

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

SM> And I'm not sure what it should return if CALLBACK is non-nil (both
SM> in the case where the request is performed asynchronously and when
SM> it's performed synchronously).
> By the docstring you gave, if CALLBACK is non-nil, it must be
> asynchronous.  So CALLBACK can't be used synchronously.

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

> 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
                       ^^^^^^^^^
                        called

> returns whatever CALLBACK returned.

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


        Stefan