From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: more url-utils? Date: Tue, 17 May 2011 17:26:15 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87mxilezg8.fsf@lifelogs.com> References: <87fwogaxzb.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1305671206 20746 80.91.229.12 (17 May 2011 22:26:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 17 May 2011 22:26:46 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 18 00:26:43 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 1QMSiw-0007n5-Ey for ged-emacs-devel@m.gmane.org; Wed, 18 May 2011 00:26:42 +0200 Original-Received: from localhost ([::1]:41052 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMSiv-0004HB-Nz for ged-emacs-devel@m.gmane.org; Tue, 17 May 2011 18:26:41 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMSit-0004Gn-5u for emacs-devel@gnu.org; Tue, 17 May 2011 18:26:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMSir-0007n5-MT for emacs-devel@gnu.org; Tue, 17 May 2011 18:26:39 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:50490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMSir-0007ma-Cd for emacs-devel@gnu.org; Tue, 17 May 2011 18:26:37 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QMSin-0007hD-1j for emacs-devel@gnu.org; Wed, 18 May 2011 00:26:33 +0200 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 May 2011 00:26:33 +0200 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 May 2011 00:26:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 79 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:itXAM95CAovkENVguMliAb+TxC4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:139471 Archived-At: On Tue, 17 May 2011 00:04:50 -0300 Stefan Monnier wrote: >> Ah, OK. So my proposal does not fit because you want backwards >> compatibility. SM> I think that's right, although I'm not completely clear on what is SM> exactly your proposal. This is my proposal, after thinking about it for a bit. Current top-level API: Dynamic binding: `url-request-data', `url-request-method' and `url-request-extra-headers' according to the docstring; also according to a comment: url-standalone-mode, url-gateway-unplugged, w3-honor-stylesheets, url-confirmation-func, url-cookie-multiple-line, url-cookie-{{,secure-}storage,confirmation}. (defun url-retrieve (url callback &optional cbargs silent) ...) (defun url-retrieve-synchronously (url) ...) Both of these result in a buffer containing "[HEADERS] [BODY]" Proposed API (based on code review throughout Emacs and my feeling for what would be "natural" in ELisp): ;;; buffer-local variables: url-retrieved-ok url-headers-alist url-headers-as-string (defmacro with-url-contents-buffer (url url-options-alist callback-closure &rest body) ...) 1) Synchronous usage with errors: (with-url-contents-buffer "http://host" '((url-request-method "POST")) nil (message "this will run SYNCHRONOUSLY since the callback-closure is nil") (message "this could throw an error") (message "Header x is %s" (assq 'x url-headers-alist)) (message "Header y is %s" (assoc "y" url-headers-alist)) (message "The headers as a string are %s" url-headers-as-string) (when url-retrieved-ok (message "The retrieval went fine")) (message "data is %s" (buffer-string)) 2) Synchronous usage without errors: (with-url-contents-buffer "http://host" '((url-request-method "POST")) 'noerror (message "this will run SYNCHRONOUSLY since the callback-closure is nil") (message "this will not throw an error")) 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")) 4) Asynchronous usage with no 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")) t (message "this will run AFTER the retrieval is done, there is no callback")) Implicitly we don't have an asynchronous mode that throws errors. I also think we should have an incremental mode where each retrieved chunk is given to the callback in the buffer as it arrives. That would let us handle large downloads better. The API would not change, though, only the `url-options-alist' would have a `url-incremental' key and the callback would look at the buffer-local variable `url-incremental-byte-offset'. SM> If you can provide a patch that give us a clean new API together with SM> some backward compatibility layer, that would be great. After we've settled on the API, please. I think the above may be too different for many :) Ted