From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/7400 Path: main.gmane.org!not-for-mail From: John Griffith Newsgroups: gmane.emacs.gnus.general Subject: Re: Feature Request. Topic Group Parameters... Date: 01 Aug 1996 10:20:40 +0200 Sender: griffith@sfs.nphil.uni-tuebingen.de Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035147719 7092 80.91.224.250 (20 Oct 2002 21:01:59 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:01:59 +0000 (UTC) Cc: griffith@filippo.sfs.nphil.uni-tuebingen.de 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 BAA19176 for ; Thu, 1 Aug 1996 01:39:19 -0700 Original-Received: from filippo.sfs.nphil.uni-tuebingen.de (filippo.sfs.nphil.uni-tuebingen.de [134.2.129.45]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 1 Aug 1996 10:20:47 +0200 Original-Received: (from griffith@localhost) by filippo.sfs.nphil.uni-tuebingen.de (8.7.5/8.7.3) id KAA05783; Thu, 1 Aug 1996 10:20:41 +0200 (MET DST) Original-To: ding@ifi.uio.no In-Reply-To: Lars Magne Ingebrigtsen's message of 31 Jul 1996 21:29:09 +0200 Original-Lines: 91 X-Mailer: Gnus v5.2.37/XEmacs 19.14 Xref: main.gmane.org gmane.emacs.gnus.general:7400 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:7400 >>>>> "LMI" == Lars Magne Ingebrigtsen writes: LMI> John Griffith writes: >> How about asking the user what should be done? >> >> Allow topics to have group parameters specified on them, but only use >> these to update group parameters on actual groups when moving groups >> into topics or changing topic-specified parameters. >> >> When changing a group parameter on a topic, ask the user if all groups >> should inherit this parameter, or whether s/he would like to go >> through each group individually, showing old values and the possible >> replacements (if they're different). (Like the initial subscription >> sequence.) LMI> I think this sounds a bit annoying. I would prefer having clear rules LMI> for topic parameter inheretance instead of requiring lots of user LMI> input when editing parameters. I agree that this could get annoying, especially if you constantly change things like I do. So here's some ideas on possible rules. Here's an example: t1 g1 g2 t2 g1 g3 t3 g2 1.1) First of all it seems that if you're going to have rules to determine inheritance, then one should be that parameters specified on the group are always preferred over those specified on topics that it is in. 1.2) And lower topics are always preferred over higher ones, so g3 would take t2's parameters over t1's. 2) Another possible rule could be that if a group (g1 above) occurs in two topics (t1 and t2) one of which is an ancestor of the other, then the parameters of the lower group should be preferred. 3) The problem is, of course, what to do with a group (g2) that occurs in two topics (t1 and t3) which are not in the ancestor relation. 3.1) The most restrictive rule would be to disallow g2 to be under t1 and t1's sister t3. But I for one find that too restrictive. 3.2) Another possibility is to give every group a "home" topic. Then that group only inherits from it's home topic, and possibly from ancestors of its home topic. This seems fairly powerful, simple and easy to understand. 3.3) A less restrictive possibility would be to allow users to specify a precedence ordering on topics to determine which topics should win in a conflict. However, it could be quite tricky to ensure that the user's rules completely avoid conflicts. 3.3.1) The simplest way would be to require a total order on topics. There could be a buffer with the list of topics, and the user could move these around. You could limit the number of topics to be moved around by only displaying those that actually have parameters specified on them. 3.3.2) You actually don't need a total order, the user could specify a partial order on topics, but then the partial order would have to be checked to make sure every group's parameters could be uniquely determined. I think this would require computing the closure of the partial order, which (I think) is O(N^3) where N is the number of topics. Could be slow with lots of topics. Even if there were very good error messages in the case of conflicts, this could be very annoying and confusing. The idea of having a home topic seems to be a nice balance between simplicity and power. This could be augmented with possible inheritance from supertopics as in rules 1.1 and 1.2. Then you could think of part of the topic hierarchy as defining a parameter inheritance hierarchy, and as part of it defining a hierarchical presentation of groups. Also, I think rule 2 wouldn't be necessary since either t1 OR t2 (exclusively) would be the home of g1. It seems like there should be some help to the user to recognize that they've, for instance, just put a group in a topic which will cause it to inherit total-expire. A lot of damage could be done very quickly. It would be nice if you could display the parameters associated with each topic and group in the topic hierarchy and to mark groups when they occur in their home topic.