From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan Moringen Newsgroups: gmane.emacs.devel Subject: Re: RFC: A framework for task management and execution in Emacs Date: Tue, 13 Jul 2010 16:36:34 +0200 Message-ID: <29561_1279031795_ZZh036L6T_WVJ.00_1279031794.2647.19.camel@steed.robot-madness> References: <22158_1279004543_ZZh033Ked6tCc.00_1279004541.2415.244.camel@steed.robot-madness> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7BIT X-Trace: dough.gmane.org 1279031815 31164 80.91.229.12 (13 Jul 2010 14:36:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Jul 2010 14:36:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 13 16:36:52 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OYgbG-000067-Jw for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 16:36:46 +0200 Original-Received: from localhost ([127.0.0.1]:53964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYgbF-0008IU-AF for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 10:36:45 -0400 Original-Received: from [140.186.70.92] (port=34846 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYgb9-0008H8-I3 for emacs-devel@gnu.org; Tue, 13 Jul 2010 10:36:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYgb7-0004KR-GA for emacs-devel@gnu.org; Tue, 13 Jul 2010 10:36:39 -0400 Original-Received: from mux2-unibi-smtp.hrz.uni-bielefeld.de ([129.70.204.73]:55457) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYgb7-0004Jx-B6 for emacs-devel@gnu.org; Tue, 13 Jul 2010 10:36:37 -0400 Original-Received: from pmxchannel-daemon.mux2-unibi-smtp.hrz.uni-bielefeld.de by mux2-unibi-smtp.hrz.uni-bielefeld.de (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <0L5I00L0038Z1Z00@mux2-unibi-smtp.hrz.uni-bielefeld.de> for emacs-devel@gnu.org; Tue, 13 Jul 2010 16:36:35 +0200 (CEST) Original-Received: from [129.70.164.69] ([129.70.164.69]) by mux2-unibi-smtp.hrz.uni-bielefeld.de (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPPSA id <0L5I00JL338YI320@mux2-unibi-smtp.hrz.uni-bielefeld.de>; Tue, 13 Jul 2010 16:36:35 +0200 (CEST) In-reply-to: X-Mailer: Evolution 2.30.2 X-EnvFrom: jan.moringen@uni-bielefeld.de X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.7.13.142414, pmx9 X-Connecting-IP: 129.70.164.69 X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127182 Archived-At: On Tue, 2010-07-13 at 12:00 +0200, joakim@verona.se wrote: > Jan Moringen writes: > > > The code of the framework described above is available at > > > > http://bazaar.launchpad.net/~scymtym/etasks/trunk/ > > > > Feedback and suggestions would be greatly appreciated. > > Sounds very interesting. I have a scanner package called "emsane" for > which I developed "emsane-postop". This is basically an event driven > transaction queue. you push operations on a queue, and when an event > happens, the operation is popped and executed. If the the operation > fails, the transaction fails. > > Does this fit in your framework? I dont have anywhere public to place > the code at yet, so I attach the file instead, so you can have a look. Thanks. There seem to be some similarities between your `emsane-postop-lisp-operation' class and my task classes. Your framework probably fits "around" mine since my concern was not so much about organizing the execution of multiple specific operations, but the specifics (like progress indication, cancellation, when and how to execute) of the execution of a single task (almost same as your operation). On the other hand, one could also wrap the execution of an entire transaction in a task (with progress, cancellation, async execution etc). This would invert the framework nesting. Maybe they are largely orthogonal after all. Kind regards, Jan