From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: more url-utils? Date: Wed, 18 May 2011 19:05:57 -0300 Message-ID: References: <87fwogaxzb.fsf@stupidchicken.com> <87mxilezg8.fsf@lifelogs.com> <87boz0eov8.fsf@lifelogs.com> <87mxikrulm.fsf@lifelogs.com> <871uzw5asv.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1305756372 22896 80.91.229.12 (18 May 2011 22:06:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 18 May 2011 22:06:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 19 00:06:07 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QMosX-0002Mt-M8 for ged-emacs-devel@m.gmane.org; Thu, 19 May 2011 00:06:05 +0200 Original-Received: from localhost ([::1]:33378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMosW-0004jn-ER for ged-emacs-devel@m.gmane.org; Wed, 18 May 2011 18:06:04 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:41045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMosT-0004jg-Lz for emacs-devel@gnu.org; Wed, 18 May 2011 18:06:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMosS-0007VS-Ke for emacs-devel@gnu.org; Wed, 18 May 2011 18:06:01 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:54375) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMosS-0007VM-Hd for emacs-devel@gnu.org; Wed, 18 May 2011 18:06:00 -0400 Original-Received: from 213-159-126-200.fibertel.com.ar ([200.126.159.213]:41120 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QMosS-0004ns-2U; Wed, 18 May 2011 18:06:00 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 139FC66140; Wed, 18 May 2011 19:05:57 -0300 (ART) In-Reply-To: <871uzw5asv.fsf@lifelogs.com> (Ted Zlatanov's message of "Wed, 18 May 2011 09:43:28 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139494 Archived-At: 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