From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/6430 Path: main.gmane.org!not-for-mail From: Kai Grossjohann Newsgroups: gmane.emacs.gnus.general Subject: Using a Gnus for collaborative work & todo list mgmt? Date: 29 May 1996 11:28:18 +0200 Sender: grossjoh@dusty.informatik.uni-dortmund.de Message-ID: Reply-To: Kai Grossjohann NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.52) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035146887 3568 80.91.224.250 (20 Oct 2002 20:48:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:48:07 +0000 (UTC) Cc: Thomas Roelleke , Christian Altenschmidt , Ulrich Pfeifer Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id DAA00931 for ; Wed, 29 May 1996 03:21:01 -0700 Original-Received: from floyd.informatik.uni-dortmund.de (floyd.informatik.uni-dortmund.de [129.217.4.40]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 29 May 1996 11:28:31 +0200 Original-Received: from dusty.informatik.uni-dortmund.de by floyd.informatik.uni-dortmund.de with SMTP (Sendmail 8.7.5/UniDo 3.11) id LAA15636; Wed, 29 May 1996 11:28:20 +0200 (MES) Original-Received: by dusty.informatik.uni-dortmund.de id AA12096; Wed, 29 May 96 11:28:19 +0200 Original-To: ding@ifi.uio.no Original-Lines: 44 X-Mailer: Gnus v5.2.2/Emacs 19.30 Xref: main.gmane.org gmane.emacs.gnus.general:6430 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:6430 Hi there, we're thinking about maintaining todo lists with Gnus for a group of people. So far, here's what we've come up with: Consider the area `emacs'. We define groups: - emacs.new: contains new todo items - emacs.cur: contains items that are currently being worked on - emacs.old: contains old items, used for reference Whenever somebody sees an article in a .new group that they want to work on they move that article into the .cur group, with their login name prepended to the subject (there's a function to do this). In the .cur group, followups and similar things can be used to update the status of each item. When the item is completely done, the whole thread is moved from .cur to .old. Now the main issue: what kind of backend could we use that - allows read/write access - doesn't cause too many problems with several people writing (I'm not even concerned about locking, it's just that I'm unsure about .overview files, for example -- what happens if somebody adds something to the .overview file while I'm reading a group -- will the new article just appear the next time I get new news?) I would think that, say, nnfolder is not a good idea because several running Emacsen may have a copy in their main memory. What happens if several people read and write the same nnml directory? We would also have to do some magic to allow `refreshing' of stuff (`I want this to (re-)appear as a new item in 2 weeks'). But I suppose that could be done by adding an emacs.susp group where each article has a header saying when to `refresh' the item. A cron job could then do the rest. I'm looking forward to hearing any suggestions you might have, kai -- Life is hard and then you die.