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: Thu, 19 May 2011 05:28:00 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87k4dnassv.fsf@lifelogs.com> References: <87fwogaxzb.fsf@stupidchicken.com> <87mxilezg8.fsf@lifelogs.com> <87boz0eov8.fsf@lifelogs.com> <87mxikrulm.fsf@lifelogs.com> <871uzw5asv.fsf@lifelogs.com> <87boyzcv0o.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1305801018 9940 80.91.229.12 (19 May 2011 10:30:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 19 May 2011 10:30:18 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 19 12:30:15 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 1QN0Ue-0003s6-Ca for ged-emacs-devel@m.gmane.org; Thu, 19 May 2011 12:30:12 +0200 Original-Received: from localhost ([::1]:56615 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN0Ud-0003vp-JB for ged-emacs-devel@m.gmane.org; Thu, 19 May 2011 06:30:11 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN0Ub-0003vj-D5 for emacs-devel@gnu.org; Thu, 19 May 2011 06:30:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN0Ua-0000gL-3S for emacs-devel@gnu.org; Thu, 19 May 2011 06:30:09 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:40925) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN0UZ-0000g0-Hq for emacs-devel@gnu.org; Thu, 19 May 2011 06:30:07 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QN0UY-0003nh-BW for emacs-devel@gnu.org; Thu, 19 May 2011 12:30:06 +0200 Original-Received: from c-67-186-102-106.hsd1.il.comcast.net ([67.186.102.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 May 2011 12:30:06 +0200 Original-Received: from tzz by c-67-186-102-106.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 May 2011 12:30:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 40 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-67-186-102-106.hsd1.il.comcast.net 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:G3e5j6Bf7Kcnn1ixxj5fQsnbiUM= 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:139507 Archived-At: On Wed, 18 May 2011 23:28:41 -0300 Stefan Monnier wrote: >> All right, I'll provide that. Are you OK with the defun* approach and SM> Sure. OK, it's on my TODO list. >> 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). SM> I think it's OK to use buffer-local vars to keep things like SM> url-header-alist. SM> [...] SM> wait, it's OK to use buffer-local vars in a buffer created for the SM> occasion (as in url-retrieve) but indeed if url-fetch stores the result SM> in the current buffer as I suggested, then it's ugly to modify the SM> buffer's local vars as a side-effect and it's better to pass it as an SM> argument to the callback. Right, `url-fetch' no longer implies `with-temp-buffer'. >> There will be a lot more function parameters on the stack, though--I >> don't know if that's a problem. SM> It's not a problem but I'd much prefer an "alist" than a "&rest SM> plist". OK. But if the status is nil we couldn't get any data so there are no URL properties. So we can have just one callback parameter "url-info" which is nil if the request failed and an alist if it worked. How would the callback find out what actually failed? Does it even need to? I think it's enough to know the request failed, the user can look in *Messages* to find out. Ted