[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more url-utils?

From: Ted Zlatanov
Subject: Re: more url-utils?
Date: Wed, 18 May 2011 09:43:28 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

On Wed, 18 May 2011 11:09:25 -0300 Stefan Monnier <address@hidden> wrote: 

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.

SM> I think you're just afraid of lambda ;-0

...or are you afraid of macros? ;)

SM> Here's my proposal:

SM> (defun url-fetch (url &optional silent callback)
SM>   "Fetch URL into current buffer.
SM> If CALLBACK is nil, do it synchronously and return a status flag."

OK.  The status flag should be nil on failure and t on success.  Let's
not tie the `url-fetch' status flag to the HTTP 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

This has less compile-time parameter validation but is much more
flexible long-term.

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.

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
returns whatever CALLBACK returned.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]