Re: more url-utils?

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 18 May 2011 09:16:07 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>>> 3) Asynchronous usage with a callback (`url-headers-alist',
>>>> `url-headers-as-string', and `url-retrieved-ok' are still available):

>>>> (with-url-contents-buffer "http://host" '((url-request-method "POST")) callback-closure
>>>> (message "this will run AFTER the retrieval and the callback-closure are done"))

SM> In which sense is this asynchronous?
>> Same as the current url.el code.

SM> So you mean that, while the `body' is run after the retrieval is done,
SM> the code after with-url-contents-buffer will be run earlier?

Yes in the asynchronous case.  This is just one case out of several the
API supports and without a body this case behaves just like
`url-retrieve'.  If you don't think the asynchronous body is a good idea
because it's hard to read, we can eliminate it by providing a separate
function for the asynchronous case that only takes a callback-closure.
To me it seems reasonable the way I've done it.

SM> What's the difference between the code run in call-back-closure from
SM> the code in `body'?

The body is easier to write explicitly but the callback-closure offers
more flexibility and backwards compatibility.  They are more or less the
same otherwise (see below for the pseudocode), it's just different types
of syntactic sugar for different situations.  I think the majority of
uses will be in the synchronous mode, where `with-url-contents-buffer'
is very convenient.

>> Since I'm proposing a macro, the callback-closure is funcalled while the
>> body is inlined.

SM> I don't know what you mean by "funcalled vs inlined" (in my world,
SM> "inlined" means it's implemented slightly differently, but the behavior
SM> is identical).

They are different because the resulting code is different, I don't know
how to explain it any better.  Maybe if I show the pseudocode?

The body passed to the macro is inlined and the callback-closure is not,
so the macro will look like this in the synchronous case:

`(with-temp-buffer
   ... get url contents ...
   ,@(when callback-closure '(funcall callback-closure))
   ,@body)

I'll need to set up a lexical bind of the callback-closure to make this
work, but I think it's reasonable otherwise.  I can write the actual
code if you agree.  Or you can tell me how the API should look.

The asynchronous case will be a bit more complicated, wrapping the body
in a temporary closure and using that as a second callback.  But as I
said above we can disallow the body in the asynchronous mode if you
think that's too complicated.

Ted