Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 43746 invoked from network); 17 Feb 2009 01:18:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Feb 2009 01:18:44 -0000 Received: (qmail 91595 invoked by uid 500); 17 Feb 2009 01:18:43 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 91555 invoked by uid 500); 17 Feb 2009 01:18:43 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 91544 invoked by uid 99); 17 Feb 2009 01:18:43 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Feb 2009 17:18:43 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates 74.125.92.25 as permitted sender) Received: from [74.125.92.25] (HELO qw-out-2122.google.com) (74.125.92.25) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Feb 2009 01:18:33 +0000 Received: by qw-out-2122.google.com with SMTP id 5so592895qwi.29 for ; Mon, 16 Feb 2009 17:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=2HWmZ3f4KL1fETi7CA20dgJgljmzEQ+OptKf7gwU7KM=; b=XPI0ILV7qxlgW+voB4WL1knAsOdiZ8uNohE2GY8z2K7a3YvMcEqHQcfP9XumoqfnMj 3jwbfuku08Tf6yKhqL/TVHc6IU2W9Wj2kYYULlGB2IhULTKd0DUHMb51Duz2nZqFekTY NqvVp4M06rhQGUNRHN7JxdlVHI31oB4CK95So= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=pmloopmegFUK3e9cViXLXwIxQo34CTuCk4xLZKREQPSr7CNFYAmd58TCbSLvBNr2Sp NNdd9S3kQenKS1dgM1jURv7ta6IGJSq72J+S114NKOb6ZQxlVQCPcKelfDK2jxFLpqN5 xSAyF9IytBtPOfLpR000vJhlo/YOUnLMqjPpc= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.224.61.11 with SMTP id r11mr9117872qah.249.1234833492413; Mon, 16 Feb 2009 17:18:12 -0800 (PST) In-Reply-To: <46aeb24f0902161700l1d288959y9a41aea46f4ccf9f@mail.gmail.com> References: <46aeb24f0902161700l1d288959y9a41aea46f4ccf9f@mail.gmail.com> Date: Mon, 16 Feb 2009 17:18:12 -0800 X-Google-Sender-Auth: 32d0af70e7a8a51d Message-ID: Subject: Re: external access to task_status methods? From: Chris Anderson To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Feb 16, 2009 at 5:00 PM, Robert Newson wrote: > All, > > I'm working on couchdb-lucene > (http://github.com/rnewson/couchdb-lucene) and would like to provide > feedback on long-running index tasks (which could take minutes > depending on the amount of change) the same way that compaction and > view generation feedback is provided. > > Specifically, some way to call add_task and update from an external. I > appreciate that cleanup is currently mediated by Erlang process > management. Externals would need a remove_task method, which is not > ideal. > > Any thoughts? > The simplest thing for now would be to manage queries for the current status within your external itself. Since incoming queries already get passed to it, it's just matter of setting up a status responder clause. -- Chris Anderson http://jchris.mfdz.com