From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: more url-utils?
Date: Wed, 18 May 2011 20:57:11 -0500 [thread overview]
Message-ID: <87boyzcv0o.fsf@lifelogs.com> (raw)
In-Reply-To: jwvoc2z3c4q.fsf-monnier+emacs@gnu.org
On Wed, 18 May 2011 19:05:57 -0300 Stefan Monnier <monnier@iro.umontreal.ca> 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
next prev parent reply other threads:[~2011-05-19 1:57 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-14 10:32 more url-utils? joakim
2011-05-14 11:21 ` Lars Magne Ingebrigtsen
2011-05-14 11:42 ` joakim
2011-05-15 1:59 ` Lars Magne Ingebrigtsen
2011-05-14 20:42 ` Dimitri Fontaine
2011-05-15 14:26 ` Jason Rumney
2011-05-16 18:25 ` Ted Zlatanov
2011-05-16 19:03 ` Stefan Monnier
2011-05-16 19:17 ` Ted Zlatanov
2011-05-16 19:22 ` Lennart Borgman
2011-05-16 19:32 ` Ted Zlatanov
2011-05-16 19:33 ` Lennart Borgman
2011-05-16 19:55 ` Ted Zlatanov
2011-05-16 19:52 ` Julien Danjou
2011-05-16 20:18 ` Ted Zlatanov
2011-05-17 3:04 ` Stefan Monnier
2011-05-17 8:13 ` Julien Danjou
2011-05-16 19:53 ` Stefan Monnier
2011-05-16 21:07 ` joakim
2011-05-16 21:18 ` Ted Zlatanov
2011-05-16 21:21 ` Lennart Borgman
2011-05-16 21:58 ` joakim
2011-05-17 11:40 ` Lars Magne Ingebrigtsen
2011-05-17 13:34 ` Stefan Monnier
2011-05-14 13:21 ` Ted Zlatanov
2011-05-16 13:15 ` Stefan Monnier
2011-05-16 15:19 ` Tom Tromey
2011-05-16 15:45 ` Stefan Monnier
2011-05-16 17:04 ` joakim
2011-05-16 17:17 ` Lennart Borgman
2011-05-16 17:30 ` Stefan Monnier
2011-05-16 18:39 ` Julien Danjou
2011-05-15 13:34 ` Chong Yidong
2011-05-17 22:26 ` Ted Zlatanov
2011-05-18 0:11 ` Stefan Monnier
2011-05-18 2:14 ` Ted Zlatanov
2011-05-18 12:16 ` Stefan Monnier
2011-05-18 13:44 ` Ted Zlatanov
2011-05-18 14:09 ` Stefan Monnier
2011-05-18 14:43 ` Ted Zlatanov
2011-05-18 22:05 ` Stefan Monnier
2011-05-19 1:57 ` Ted Zlatanov [this message]
2011-05-19 2:28 ` Stefan Monnier
2011-05-19 10:28 ` Ted Zlatanov
2011-05-19 11:53 ` Stefan Monnier
2011-05-19 12:43 ` Ted Zlatanov
2011-05-19 13:28 ` Stefan Monnier
2011-05-19 13:35 ` Ted Zlatanov
2011-05-30 17:31 ` Lars Magne Ingebrigtsen
2011-05-30 19:09 ` Stefan Monnier
2011-05-30 19:38 ` Lars Magne Ingebrigtsen
2011-05-30 22:17 ` Stefan Monnier
2011-05-30 23:11 ` Lars Magne Ingebrigtsen
2011-05-31 1:26 ` Stefan Monnier
2011-05-31 10:15 ` Lars Magne Ingebrigtsen
2011-05-31 12:45 ` Stefan Monnier
2011-05-31 18:38 ` Lars Magne Ingebrigtsen
2011-05-19 14:11 ` joakim
2011-05-19 14:40 ` Stefan Monnier
2011-05-19 13:46 ` ELisp futures and continuations/coroutines (was: more url-utils?) Ted Zlatanov
2011-05-19 14:15 ` ELisp futures and continuations/coroutines Stefan Monnier
2011-05-19 14:16 ` joakim
2011-05-19 15:24 ` Ted Zlatanov
2011-05-19 15:09 ` Thien-Thi Nguyen
2011-05-19 15:31 ` Ted Zlatanov
2011-05-19 16:40 ` Thien-Thi Nguyen
2011-05-19 23:48 ` Ted Zlatanov
2011-05-20 1:23 ` Thien-Thi Nguyen
2011-05-20 4:18 ` Mohsen BANAN
2011-05-20 15:30 ` Ted Zlatanov
2011-05-20 15:29 ` Ted Zlatanov
2011-05-22 13:17 ` Thien-Thi Nguyen
2011-05-23 14:24 ` Ted Zlatanov
2011-05-23 14:59 ` Stefan Monnier
2011-05-23 15:10 ` Ted Zlatanov
2011-05-23 15:42 ` SAKURAI Masashi
2011-05-25 2:07 ` Ted Zlatanov
2011-05-26 0:23 ` SAKURAI Masashi
2011-06-03 13:59 ` SAKURAI Masashi
2011-06-03 16:06 ` Ted Zlatanov
2011-06-04 6:21 ` SAKURAI Masashi
2011-06-29 5:31 ` SAKURAI Masashi
2011-06-29 12:01 ` Ted Zlatanov
2011-06-29 17:33 ` SAKURAI Masashi
2011-06-29 16:09 ` Chong Yidong
2011-05-23 15:45 ` Stefan Monnier
2011-05-25 2:02 ` Ted Zlatanov
2011-05-31 10:53 ` Ted Zlatanov
2011-05-31 16:55 ` Ted Zlatanov
2011-05-19 17:03 ` ELisp futures and continuations/coroutines (was: more url-utils?) SAKURAI Masashi
2011-05-19 22:51 ` ELisp futures and continuations/coroutines Ted Zlatanov
2011-05-20 15:49 ` SAKURAI Masashi
2011-05-25 2:17 ` Ted Zlatanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87boyzcv0o.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.