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 23:28:41 -0300 Message-ID: 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 1305772135 29824 80.91.229.12 (19 May 2011 02:28:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 19 May 2011 02:28:55 +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 04:28:51 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 1QMsyo-0007M5-11 for ged-emacs-devel@m.gmane.org; Thu, 19 May 2011 04:28:50 +0200 Original-Received: from localhost ([::1]:54244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMsyn-0003G0-G4 for ged-emacs-devel@m.gmane.org; Wed, 18 May 2011 22:28:49 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMsyj-0003Fj-Um for emacs-devel@gnu.org; Wed, 18 May 2011 22:28:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMsyj-0001Mp-4r for emacs-devel@gnu.org; Wed, 18 May 2011 22:28:45 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:39970) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMsyj-0001Mj-3J for emacs-devel@gnu.org; Wed, 18 May 2011 22:28:45 -0400 Original-Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:52491 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QMsyi-0003iQ-JM; Wed, 18 May 2011 22:28:44 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id CD5C96621E; Wed, 18 May 2011 23:28:41 -0300 (ART) In-Reply-To: <87boyzcv0o.fsf@lifelogs.com> (Ted Zlatanov's message of "Wed, 18 May 2011 20:57:11 -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:139497 Archived-At: > Yeah. So perhaps we simply write `url-http-fetch' that specifies the > base `url-fetch' props and then adds its own list on top. Hmm... maybe that's the right approach, indeed, but I wouldn't know (for lack of experience). > All right, I'll provide that. Are you OK with the defun* approach and Sure. > having each `url-{http,ftp,etc}-fetch' function build on the base > `url-fetch'? It doesn't sound too bad, tho maybe I'd have expected that url-fetch calls one of url--fetch, rather than the other way around. > 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). I think it's OK to use buffer-local vars to keep things like url-header-alist. [...] wait, it's OK to use buffer-local vars in a buffer created for the occasion (as in url-retrieve) but indeed if url-fetch stores the result in the current buffer as I suggested, then it's ugly to modify the buffer's local vars as a side-effect and it's better to pass it as an argument to the callback. > There will be a lot more function parameters on the stack, though--I > don't know if that's a problem. It's not a problem but I'd much prefer an "alist" than a "&rest plist". Stefan