From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/49934 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: Move messages while offline using registry? Date: Fri, 07 Feb 2003 21:09:11 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: owner-ding@hpc.uh.edu Message-ID: References: <844r7fzro3.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1044669499 10403 80.91.224.249 (8 Feb 2003 01:58:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 8 Feb 2003 01:58:19 +0000 (UTC) Cc: ding@gnus.org Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18hKG0-0002ha-00 for ; Sat, 08 Feb 2003 02:58:17 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18hKHE-0005xi-00; Fri, 07 Feb 2003 19:59:32 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 07 Feb 2003 20:00:28 -0600 (CST) Original-Received: from sclp3.sclp.com (sclp3.sclp.com [66.230.238.2]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id UAA23590 for ; Fri, 7 Feb 2003 20:00:16 -0600 (CST) Original-Received: (qmail 79594 invoked by alias); 8 Feb 2003 01:59:15 -0000 Original-Received: (qmail 79589 invoked from network); 8 Feb 2003 01:59:15 -0000 Original-Received: from ns3.beld.net (208.229.215.83) by 66.230.238.6 with SMTP; 8 Feb 2003 01:59:15 -0000 Original-Received: from heechee.beld.net (dhcp-0-30-bd-1-93-b2.cpe.beld.net [24.233.66.27]) by ns3.beld.net (Postfix) with ESMTP id B77E33B969; Fri, 7 Feb 2003 20:59:09 -0500 (EST) Original-To: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) 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" Mail-Followup-To: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann), ?=@ns3.beld.net, ding@gnus.org In-Reply-To: (Ted Zlatanov's message of "Fri, 07 Feb 2003 17:54:12 -0500") User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:49934 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:49934 On Fri, 07 Feb 2003, tzz@lifelogs.com wrote: > Shouldn't be too hard. Insert (in the global registry that's still > to come) something like this associated with the message ID: > > '('queued-move-when-connected group-name) > > then on startup, Gnus can scan the registry and (if connected) do > the move. I was thinking more about this, and it seems to me like a Gnus action handler would be a nice thing. Consider the current situation: there are hundreds of functions, a dozen per backend, that follow a naming convention - for instance, nnimap-request-newgroups which corresponds to the 'request-newsgroups action. What if, instead of running those functions directly, user requests put actions (for instance, 'request-newsgroups) on a queue, and then Gnus could process those actions off the queue as they come in? Each backend would have its own action handler, and a central routing function would send each action from the main queue to the appropriate action handler in the respective backend. This, of course, applies only to non-interactive actions, such as "move article" or "set mark." To create complex behavior for a message - for instance, "move to group X and set mark to Y" simple actions can be queued as a group. A big advantage is that the queue can be traced backwards, providing a limited sort of undo. Of course, a deleted message can't be recovered, but an article move or erroneous spam processing of a ham article could be retraced backwards. That would be a good thing, I think. Another advantage is that offline work becomes simply a matter of saving up the event queue until Gnus is online again. Maybe asynchronous events can be implemented in this event queue, so a user can read one article while another is being moved or copied. I don't know how well Emacs can handle this, but asynchronous events could be limited to only a few "safe" combinations. Things like the message registry, spam/ham processing, and any code that needs to know the *past* of an article, not just its current state, would be much simpler this way. It seems to me that this is a significant amount of work, and maybe it doesn't make sense to change Gnus in such a fundamental way (either because the gains are not worth the effort, or because it's too much work altogether). What do you think? Ted