brad@looking.on.ca (Brad Templeton) (11/14/89)
I have come to wonder if crossposting is all that useful in discussion groups. On ClariNet, I use it a lot for news articles, where wire items that cover multiple topics are posted to multiple groups. But for discussion, I have begun to doubt the value. Even if a base article does cover multiple group topics, the whole discussion almost never does. And nobody bothers with followup-to headers. In fact, it just seems to get annoying. In addition, we get the annoying "posting to a zillion groups" by people who think they should get as many people as possible to read their articles rather than attempting to classify them well. Other than for news items classified in a semi-regular manner, I have come to doubt the value of crossposting. Yes, it does save disk space, and if you believe that crossposting is going to happen anyway, you might as well save the disk space, and allow readers to show the article only once. But on other systems (Usenet is the only one I know of that supports cross-posting so extensively) I just don't see much manual crossposting. (ie. posting N times to N groups) In fact, I see manual crossposting on USENET even more than I see it elsewhere. Am I alone in this? I would think that perhaps if an original article is crossposted, we should get down to it and insist the followups be in one group. That should either be a group picked in a followup-to line, or the first group, or followers-up should be asked to pick which of the groups they are going to reply within. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
tneff@bfmny0.UU.NET (Tom Neff) (11/14/89)
One approach would be to require news admin approval for any article crossposted to more than, say, 3 groups (a configurable option). Where newsgroups are efficiently orthogonal, a little crossposting can be terrific. For instance I just crossposted a question about the AT&T 6386 WGS Unix box to comp.sys.att and comp.unix.i386. I could have posted two separate articles if crossposting didn't exist, but people who read both groups would have had to read the question twice. Crossposting is a tool that can be used or misused. I don't think it's fair to punish those who know what it's for, just because some silly people don't. It would be better to put some reasonable limits on it, like admin approval as mentioned above. It's a fair bet that anyone with a legitimate need for appropriate crossposting will either have approval privileges him- or herself, or be about ten seconds away from the person who does. It's the C.C. back bench twits you want to discourage ever so slightly. :-) -- "UNIX should be used :: Tom Neff <tneff@bfmny0.UU.NET> or as an adjective." -- AT&T :: ...uunet!bfmny0!tneff (UUCP only)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (11/15/89)
Yes people do crosspost. Some discussions are appropriate in several groups, others are not. It is more annoying when the discussion wanders from the original (possibly appropriate) topic. However, since the cross postings take little or no extra space, and you only see them once with a good reader, what do you want us to do about it? It's a small problem, hard to solve because many people want to cross post, and you seem to think it's more important than I do. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
coolidge@brutus.cs.uiuc.edu (John Coolidge) (11/15/89)
brad@looking.on.ca (Brad Templeton) writes: >I have come to wonder if crossposting is all that useful in discussion >groups. On ClariNet, I use it a lot for news articles, where wire items >that cover multiple topics are posted to multiple groups. I'm fairly certain that it is useful. The real value seems to come in when a discussion has gone on for a while and someone decides that it's a good time to 'call in the experts'. The 'experts' from another group can contribute without the original posters having to group- chase all over the place. >But on other systems (Usenet is the only one I know of that supports >cross-posting so extensively) I just don't see much manual crossposting. >(ie. posting N times to N groups) In fact, I see manual crossposting on >USENET even more than I see it elsewhere. Am I alone in this? I think people don't do manual crossposting because it's difficult and because the local culture is against it. Most of Illinois runs notes, not news. Notes doesn't have crossposting. In the local notesfiles (aka newsgroups) people _do_ manually crosspost every so often. This winds up being very annoying, because two separate local groups are discussing the same thing --- and half the time the same point gets made in each discussion because one set of people didn't know that the other set was arguing that point. >I would think that perhaps if an original article is crossposted, we should >get down to it and insist the followups be in one group. That should either >be a group picked in a followup-to line, or the first group, or followers-up >should be asked to pick which of the groups they are going to reply within. I don't like this, mainly because in the case of discussions that _do_ belong in two groups at the same time people who only read one group have to subscribe to the other one or miss out. This happens often enough that I think crossposting is a useful solution. I think the entire point of newsgroups is to section off the discussion space and make it easier for people to find others talking about what they want to discuss. When the newsgroup system would hinder instead of helping that goal (like in systems without crossposting, where newsgroups hide discussions), it's better to work around the newsgroup system. Crossposting does that by allowing 'virtual newsgroups' specific to one discussion to temporarily exist. --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1989 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well. New NNTP connections always available! Send mail if you're interested.
allbery@NCoast.ORG (Brandon S. Allbery) (11/15/89)
As quoted from <47326@looking.on.ca> by brad@looking.on.ca (Brad Templeton): +--------------- | I would think that perhaps if an original article is crossposted, we should | get down to it and insist the followups be in one group. That should either | be a group picked in a followup-to line, or the first group, or followers-up | should be asked to pick which of the groups they are going to reply within. +--------------- Once again, with feeling: (Remove the trailing "\" from each line and join into a single long line.) -ENEWSHEADER="Newsgroups: %F\\nSubject: Re: %S\\nReferences: %i\\n\ Followup-To: %(%F=^\\([^,]*\\),.*$?%1:%F)\\nDistribution: %D\\n\ Organization: %o\\n\\n" The expression in the Followup-To: line automatically forces Followup-To: to specify the first newsgroup of the cross-post list. Truly paranoid sysadmins might want to copy the expression to the Newsgroups: line as well. Note that this now incorporates the "% interp buffer overflow" hack of including only the previous article in the References: line. Also note that I have removed the Reply-To: line, which is redundant, unnecessary, and requires a hard-coded domain (ugh). ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)* expnet.all: Experiments in *net management and organization. Mail me for info.
chip@ateng.com (Chip Salzenberg) (11/15/89)
According to brad@looking.on.ca (Brad Templeton): >I would think that perhaps if an original article is crossposted, we should >get down to it and insist the followups be in one group. Not insist. Make the default, yes, but not insist. -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg at A T Engineering; <chip@ateng.com> or <uunet!ateng!chip>
karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) (11/15/89)
brad@looking.on.ca writes: >I would think that perhaps if an original article is crossposted, we should >get down to it and insist the followups be in one group. chip@ateng.com writes: Not insist. Make the default, yes, but not insist. 2.11.17 and later does this.
lemke@radius.UUCP (Steve Lemke) (11/15/89)
In article <1604@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: } } However, since the cross postings take little or no extra space, and }you only see them once with a good reader, what do you want us to do }about it? OK, question: I'm running news 2.11 and it has the Xref lines in each message, but rn still shows me the messages several times - once in each group it's crossposted to. Where did I blow it and how do I make it so I only see the messages once? If there is a simple answer, this may benefit others with the same problem. However, in the interest of saving net.bandwidth, please reply to me at radius!lemke@apple.com and I'll post if there's sufficient interest.
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/15/89)
>>I would think that perhaps if an original article is crossposted, we should >>get down to it and insist the followups be in one group. > >Not insist. Make the default, yes, but not insist. Don't insist, in fact, make it difficult to do. If an article is posted to a set of reasonable groups, followups to it *should* stay in all the groups (at least until the discussion wanders so far off track that it no longer belongs in some of the groups). It's very annoying to have either disappearing threads or have to go track down and subscribe to a newsgroup you are not generally interested to find the responses to some article. What problem are you trying to fix? -- Branch Technology <zeeff@b-tech.ann-arbor.mi.us>
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/16/89)
Think of the newsgroups not as a distinct wall but as a list of keywords chosen from a fixed list that help people determine if they are interested in a thread. As long as a thread remains of interest to these people its "keywords" should remain intact. In my opinion, when you respond you should be presented with the list of newsgroups and the question "Is this discussion still of interest to these groups?". -- Jon Zeeff Branch Technology <zeeff@b-tech.ann-arbor.mi.us> Fax: (313) 995-1931 <zeeff%b-tech@iti.org>
coolidge@brutus.cs.uiuc.edu (John Coolidge) (11/16/89)
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >>>I would think that perhaps if an original article is crossposted, we should >>>get down to it and insist the followups be in one group. >>Not insist. Make the default, yes, but not insist. >Don't insist, in fact, make it difficult to do. If an article is >posted to a set of reasonable groups, followups to it *should* stay in >all the groups (at least until the discussion wanders so far off track >that it no longer belongs in some of the groups). It's very annoying >to have either disappearing threads or have to go track down and >subscribe to a newsgroup you are not generally interested to find the >responses to some article. I agree. Trying to follow a discussion in multiple newsgroups is a major pain. It's much easier to simply use crossposting the way it was intended to be used: to make it _easier_ to find the information you're interested in. I've seen many cases where someone tried to "help" by limiting followups to only one group (when both were clearly appropriate), and they were usually met with (IMHO justified) protests and flames. Limiting a discussion appropriate to multiple groups to just one of the groups doesn't help anyone; it hinders the readers of one group or the other in their attempts to find information useful to them. Even worse: what happens if two different people reply to the article, each aiming follow-ups to a different group. Then third parties re-crosspost their responses, because it _is_ appropriate to both groups. Now readers in _both_ groups are seeing responses to articles they've never seen. Argh! Sounds like the principle of _maximum_ inconvenience to me... >What problem are you trying to fix? That's what I've been wondering. This doesn't stop the irrelevant crossposting problem --- it just ensures that only one group's readers will see the flamage resulting. Stopping crossposts entirely just leads to the broad crossposters multiposting and wasting everyone's disk space. It also makes it harder to find the articles I'm interested in, because I have to paw through even more groups. --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1989 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well. New NNTP connections always available! Send mail if you're interested.
perry@ccssrv.UUCP (Perry Hutchison) (11/16/89)
In article <47326@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: > Even if a base article does cover multiple group topics, the whole > discussion almost never does. And nobody bothers with followup-to headers. ^^^^^^ A bit overstated, I think, but certainly they are not widely used. > I would think that perhaps if an original article is crossposted, we should > ... insist the followups be in one group ... either a group picked in a > followup-to line, or the first group ... How about (as an amendment to whatever RFC): If the Newsgroups: line specifies more than one group, the Followup-To: line is required, and must contain either a single valid group name, or an email address, or the word "poster". (In the latter two cases followups are treated as replies.) Implementation could easily be made upward compatible. New (or revised) posting programs would prompt for the followup group, if not specified. To maximize compliance in the presence of older posting programs, the originating transport program (e.g. inews) could check for cross-postings without a Followup-To: and insert one, specifying the first-listed newsgroup. -- The "From" address in the header does not work. This does: ... tektronix!sequent!ccssrv!perry
bzs@world.std.com (Barry Shein) (11/17/89)
>I have come to wonder if crossposting is all that useful in discussion >groups. On ClariNet, I use it a lot for news articles, where wire items >that cover multiple topics are posted to multiple groups. > >But for discussion, I have begun to doubt the value. Even if a base >article does cover multiple group topics, the whole discussion almost never >does. And nobody bothers with followup-to headers. [you should have probably cross-posted this to news.misc :-] Are you working from an assumption that there's too much noise, volume, stuff and therefore "let's take a hard look at the value of cross-posting" or are you working from the assumption that cross-posting, in the abstract, has no real value in a discussion forum no matter how well the mechanisms work to support it? In practice, well, it may be a symptom more than a disease. I suppose one can point at the ills it causes but I'm not sure that's not like saying that there should only be one newspaper because once you have a bunch it's too much to read, and people just get confused anyhow, etc. In the abstract it seems to make good sense, someone wants to know something about, oh, what are people's experiences with some stereo system. So they cross-post to rec.audio and misc.consumers. A bad idea? I don't see why (again, in the abstract.) I doubt the cross-section completely overlaps and, most likely, you'll get the audiophiles' views from rec.audio and John (Jane) Doe's views from misc.consumers. It can be valuable. I guess my point is, is the evil cross-posting or is it something else and stopping cross-posting might help *that*, but possibly at some valuable cost? -- -Barry Shein Software Tool & Die, Purveyors to the Trade | bzs@world.std.com 1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs
brad@looking.on.ca (Brad Templeton) (11/17/89)
Well I've been thinking about crossposting because I have been thinking about moving net software to other operating systems. Many other systems don't support links, so if you wish to support crossposting you either have to a) waste disk space, or b) use another file structure. Crossposting, in many places, does more harm that good right now, which is not to say that it doesn't have value, just that on the whole it may be a losing suggestion. In general this is part of an investigation into other forms the news database could take. The current system, one article per file in newsgroup directories, has the merit of simplicity. It fits into unix well, and people can come in to a newsgroup directory and manually look around and it's all fairly easy to deal with. I thought of just leaving articles in their batches, and writing index files in the newsgroups with the seek addresses and lengths. This has a number of advantages -- no links are needed for crossposts, you don't waste space due to the 1K disk block (or bigger -- 4K on DOS) and best of all, unbatching isn't unbatching at all -- you preserve the batches almost as is, so it's a very fast process -- faster even than C news. Plus you can play around with compression etc. But you break all existing readers. With 1K disk blocks, the space wastage is about 16%. More if you compress headers due to the number of short articles. But 16% isn't enough. It's less than 1 megabyte a day. And a megabyte of disk space only costs about $6, so a 30 day expire sves you $180. Not worth it from that standpoint. With 4K blocks, and no links, as on DOS, I would say the gain is more serious. In the end, I suspect the answer is the current format with some supplemental files. I think that's what NN does, isn't it? Where can I get a user manual or low-level implementation manual for NN? (Probably look on uunet, right.) -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
brad@looking.on.ca (Brad Templeton) (11/17/89)
In article <1989Nov14.195710.11774@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes: >Note that this now incorporates the "% interp buffer overflow" hack of >including only the previous article in the References: line. Also note that >I have removed the Reply-To: line, which is redundant, unnecessary, and >requires a hard-coded domain (ugh). ACK!!! STOP!!!! Please don't only include the parent article in the references line! If you must trim it down, then include at the very least the 'root' article and the parent. I think there was a move afoot to modify the RFC to say that. If we are ever going to get software the makes use of the references line (I've been experimenting with some tonight, and the results are beautiful -- I never knew USENET could be so clear and easy to deal with when displayed as a graphical tree) then we should at least preserve the root. Otherwise the software has to work a lot harder. But the beauty of that tree is tainted by all the subthreads that get zoomed to the top because of broken references lines. It could be soooo good. What this means is that a references-using reader either has to a) do a lot of hairy, time consuming things to re-link broken lines, or b) work only with a inews program that does the hairy things. The latter is clearly more efficient, but requiring people to change their inews just to run a new reader is more painful. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
tneff@bfmny0.UU.NET (Tom Neff) (11/18/89)
In article <48886@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >Well I've been thinking about crossposting because I have been thinking >about moving net software to other operating systems. > >Many other systems don't support links, so if you wish to support >crossposting you either have to a) waste disk space, or b) use another >file structure. Trivially untrue!?... if you're porting News over to some other system where "real" links aren't supported, just write a one-line file saying "-> Link to file ABCDEFG.123" and do the "link" yourself. If this would waste too much disk space, you can have ONE file of "links" in each newsgroup storage area, and search that list for "linked" articles. -- Knowing *when* to optimize is just >>>/ Tom Neff as important as knowing *how*. /<<< tneff@bfmny0.UU.NET
coolidge@brutus.cs.uiuc.edu (John Coolidge) (11/18/89)
perry@ccssrv.UUCP (Perry Hutchison) writes: >How about (as an amendment to whatever RFC): > If the Newsgroups: line specifies more than one group, the Followup-To: > line is required, and must contain either a single valid group name, or > an email address, or the word "poster". (In the latter two cases > followups are treated as replies.) >Implementation could easily be made upward compatible. New (or revised) >posting programs would prompt for the followup group, if not specified. >To maximize compliance in the presence of older posting programs, the >originating transport program (e.g. inews) could check for cross-postings >without a Followup-To: and insert one, specifying the first-listed newsgroup. ACK! Not only do we have a bogus requirement that only one group contain followups, but we get to engage in gratuitous header rewriting to enforce it. There are many useful discussions that really belong to more than one group. Forcing followups to just one group means that the readers of one group or the other will be inconvenienced by having to hunt for the responses. Discussions are more likely to diverge, furthur inconveniencing readers. Crosspostings are a feature, not a bug. They decrease the amount of time readers have to spend chasing all over the namespace trying to find the articles they're interested in. I ask again: what problem exactly are you (those trying to modify crossposting) trying to solve? --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1989 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well. New NNTP connections always available! Send mail if you're interested.
loverso@Xylogics.COM (John Robert LoVerso) (11/18/89)
In article <48886@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes about a news implementation where articles are left in the batches, and instead an index file is used to access them. He goes on to say: > But you break all existing readers. Actually, you only break those readers which have, hardcoded into them, the storage scheme for some existing news implementations. Readers using NNTP wouldn't have this problem. (You'd just have to fix the NNTP server). John -- John Robert LoVerso Xylogics, Inc. 617/272-8140 loverso@Xylogics.COM Annex Terminal Server Development Group
eps@toaster.SFSU.EDU (Eric P. Scott) (11/18/89)
In article <1989Nov17.173753.9790@brutus.cs.uiuc.edu> coolidge@cs.uiuc.edu writes: >Crosspostings are a feature, not a bug. I agree with John on this one, and for other reasons. We use netnews software to handle non-usenet hierarchies. Oh my! I have nothing against policy-making, but breaking one hand doesn't make the other feel better. It's amazing what a few well-written reminders in postnews/Pnews will accomplish when it comes to engendering responsible behavior. Treating the "seven sisters" specially is ok by me, so long as private subnetworks can be run the way their administration deems appropriate. ------- IMHO: Crossposting is "less of a problem" than having Folloup-To: different from Newsgroups:--I may find myself in the middle of a discussion and there's no way in My Favorite Newsreader(tm) to follow References: if the message IDs came from another newsgroup. What's needed is a way to retrieve the history record for a given Message-ID (which may not be all that helpful if the referenced article has expired, or came from a foreign distribution, but is more than I have now). MFN(tm) may or may not be using NNTP, and shouldn't really have any knowledge of how history information is actually stored. -=EPS=-
tale@pawl.rpi.edu (David C Lawrence) (11/18/89)
In <48887@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes:
Brad> Please don't only include the parent article in the references
Brad> line! If you must trim it down, then include at the very least
Brad> the 'root' article and the parent. I think there was a move
Brad> afoot to modify the RFC to say that.
Why? Inheritance makes keeping any but the most recent reference
around unnecessary. I am looking at article <3@foo.bar> and see one
person quoted, the one who wrote <2@foo.bar>. <2@foo.bar> referenced
<0@foo.bar> but no reference was made to it except through some
indirection. When I back trace through the articles referenced by the
Message-IDs I find the parent of the thread was <sqrt[-1]@foo.bar>.
Keeping redundant data sets around is not necessary to accomplish that.
Dave
--
(setq mail '("tale@pawl.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))night@pawl.rpi.edu (Trip Martin) (11/18/89)
In <1989Nov17.231128.20369@rpi.edu> tale@pawl.rpi.edu (David C Lawrence) writes: >Why? Inheritance makes keeping any but the most recent reference >around unnecessary. I am looking at article <3@foo.bar> and see one >person quoted, the one who wrote <2@foo.bar>. <2@foo.bar> referenced ><0@foo.bar> but no reference was made to it except through some >indirection. When I back trace through the articles referenced by the >Message-IDs I find the parent of the thread was <sqrt[-1]@foo.bar>. >Keeping redundant data sets around is not necessary to accomplish that. This breaks if you're missing an article in the chain. I don't know how much of a problem this would be in practice, though. A suspect uucp sites would have a much greater problem with this than internet sites. It's pretty much a tradeoff. You could greatly reduce the chance of a broken thread by keeping around the parent and grandparent message-ids. That way, both parent and grand- parent articles would have to be lost before a thread is broken. I think this would be highly unlikely. It doesn't increase the references line by much either. -- Trip Martin KA2LIV Trip_Martin@mts.rpi.edu night@pawl.rpi.edu night@uruguay.acm.rpi.edu ** Murphy's Law of Thermodynamics: Things get worse under pressure **
karl@ddsw1.MCS.COM (Karl Denninger) (11/19/89)
In article <1989Nov17.231128.20369@rpi.edu> tale@pawl.rpi.edu (David C Lawrence) writes: >In <48887@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >Brad> Please don't only include the parent article in the references >Brad> line! If you must trim it down, then include at the very least >Brad> the 'root' article and the parent. I think there was a move >Brad> afoot to modify the RFC to say that. > >Why? Inheritance makes keeping any but the most recent reference >around unnecessary. I am looking at article <3@foo.bar> and see one >person quoted, the one who wrote <2@foo.bar>. <2@foo.bar> referenced ><0@foo.bar> but no reference was made to it except through some >indirection. When I back trace through the articles referenced by the >Message-IDs I find the parent of the thread was <sqrt[-1]@foo.bar>. >Keeping redundant data sets around is not necessary to accomplish that. NO NO NO NO! PLEASE do as Brad has suggested. There are myriad reasons, but picture this one for starters: o Each thread of discussion is a file (saving lots of disk space when you have only one overhead of <x>% per >thread< rather than per posting) o Each followup and main item has an entry in a database (Item-Id's) o Followups are attached as they come in to the relavent article base. Now, how do you find the "base"? Well, with either the parent or the "base" item you can find it -- providing that you (1) have ALL the followups prior to the one you just received, AND (2) you don't mind going back <n> levels in the search. Lose one followup in the chain and you may be >screwed<. Let's say you have this set-up: Item: <416@hosedsite> Resp: <417@hosedsite> Resp: <418@hosedsite> Now you get <666@newsite>. It has as a references line: References: <418@hosedsite> All is well. We can find that. Now assume you lost (or haven't yet gotten) <418@hosedsite>. How do you figure out how the item in question is to be filed? If you keep the base item in the references line this problem disappears. Now you need nothing other than the base (which you had better already have received, otherwise the followup isn't likely to make too much sense!). We have newsreading and posting software which does exactly this. It trims the references line, but keeps the immediate parent AND the base item. It works great -- except when some idiot hacks up (or worse, DELETES) the references line.... then you get parallel discussion threads which contain the same discussion but are in different places (yuck). -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
brad@looking.on.ca (Brad Templeton) (11/19/89)
In article <14927@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >>Many other systems don't support links, so if you wish to support >>crossposting you either have to a) waste disk space, or b) use another >>file structure. > >Trivially untrue!?... if you're porting News over to some other system >where "real" links aren't supported, just write a one-line file saying >"-> Link to file ABCDEFG.123" and do the "link" yourself. If this would >waste too much disk space, you can have ONE file of "links" in each >newsgroup storage area, and search that list for "linked" articles. Creating a one line file (for example, under MS-DOS where that can take 4K) comes under my definition of wasting disk space! Even a 1K file comes under that definition. The best solution is probably a new file structure, where you simulate unix directories to a small extent, with files of pointers to the actual text. (Or even files of message-ids, which are mapped to pointers to the text.) -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
brad@looking.on.ca (Brad Templeton) (11/19/89)
Yes, it may not seem necessary to keep around the whole references chain. But if you don't, it requires a tremendous amount of work on the part of the rnews program or newsreader to rebuild it. The main use of References, as I see it, is not just to allow one to move 'up' to the parent of an article. While that is a valid use, a far more useful facility is the ability to deal with usenet as a series of message trees. If you want to deal with usenet as a series of trees, you can either represent the tree in the article, or you can build the tree. You can either build the tree as the articles come in, in the rnews process, or you can try to build the tree in the reader. Building it in the reader is so slow as to be almost pointless. But building it in the rnews program also slows that down -- even more than the reader, which at least is probably already dealing with a pile of articles in the same group. If you build the tree at rnews time, you end up using most of the disk space. If you don't use up that disk space, then when the root of the tree expires, the most important info about the tree structure is erased. I am beginning to think the References line can be the most valuable header line in a USENET article. Nobody uses it yet, but I have written some test software to use it, and if you ignore the broken reference lines out there now, the result is WOW! It's a whole new network. I am seriously thinking of expanding this into a tree based newsreader. But if we are going to add deliberately broken references lines to the problem of the accidentally broken ones we have now, that could be scuttled. ------- I already have (and sell) a tool that does limited tree-based manipulation. (Or rather, can do just about anything, and using the trees is one obvious application of it.) With such a tool, if one subtree wanders off into puns, or point by point rebuttal-wars, you can just prune that subtree, and still track exactly the parts of the discussion you think are valuable. This is more and more important as the net gets bigger. The only problem is the broken lines. I prune a subtree, or more often a whole tree, and it keeps coming back when people break the references line to disconnect their article from the node that was pruned. As I pointed out recently, "Results of sci.aquaria" came back *10* times, because Richard Sexton says, "I remove the references line because it clutters my screen." RN kill files have the same problem in reverse. While they can only kill entire trees, they do not use the references line and thus don't get bothered when it is broken. But if the subject changes (as it usually should as most threads wander or become more specific) RN shows it to you again and again. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
allbery@NCoast.ORG (Brandon S. Allbery) (11/19/89)
As quoted from <48887@looking.on.ca> by brad@looking.on.ca (Brad Templeton): +--------------- | In article <1989Nov14.195710.11774@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes: | >Note that this now incorporates the "% interp buffer overflow" hack of | >including only the previous article in the References: line. Also note that | | ACK!!! STOP!!!! | | Please don't only include the parent article in the references line! If you | must trim it down, then include at the very least the 'root' article and | the parent. I think there was a move afoot to modify the RFC to say that. > ( . . . ) | What this means is that a references-using reader either has to | a) do a lot of hairy, time consuming things to re-link broken lines, or | b) work only with a inews program that does the hairy things. | | The latter is clearly more efficient, but requiring people to change their | inews just to run a new reader is more painful. +--------------- Brad, long References: lines currently break both rn and 2.11.19 inews. Until *both* are officially modified and propagated to a sufficiently large percentage of sites, something is going to break anyway. (2.11.19's breakage is worse, because it effectively corrupts the article for downstream sites.) It's *already* broken. My hack is exactly that -- a hack to mitigate the problems with broken software that already mis-handles References: lines. We need to fix the software, yes, but until that is done something is needed to make existing news software bugs not get triggered. Consider the hack a band-aid: it's necessary now, but who wears a band-aid for their entire lifetime? I'll remove the hack when it isn't needed. In the meantime, push for fixing the software so I won't need the hack any more. ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)* expnet.all: Experiments in *net management and organization. Mail me for info.
tneff@bfmny0.UU.NET (Tom Neff) (11/19/89)
The two extreme positions "keep only the latest reference" versus "keep the whole chain regardless of length" are not the only workable options. A compromise is possible: keep the root ID and the last up-to-N parent ID's. As each new followup is added to a long discussion, the first reference (the root) is retained in-place, and the newest reference ID shifted into the 2nd-thru-last reference list. ref: <a> <b> <c> <d> <e> ref: <a> <c> <d> <e> <f> ref: <a> <d> <e> <f> <g> etc. This way, root-based thread management systems stay happy, context-based managers have the maximal chance to place an article where it belongs (since there are multiple ancestors listed), but the overall length of the references line stays manageable. -- Psychoanalysis is the mental illness \\\ Tom Neff it purports to cure. -- Karl Kraus \\\ tneff@bfmn0.UU.NET
coolidge@brutus.cs.uiuc.edu (John Coolidge) (11/19/89)
karl@ddsw1.MCS.COM (Karl Denninger) writes: >In article <1989Nov17.231128.20369@rpi.edu> tale@pawl.rpi.edu (David C Lawrence) writes: >>In <48887@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >>Brad> Please don't only include the parent article in the references >>Brad> line! If you must trim it down, then include at the very least >>Brad> the 'root' article and the parent. I think there was a move >>Brad> afoot to modify the RFC to say that. >> >>Why? Inheritance makes keeping any but the most recent reference >>around unnecessary. >Lose one followup in the chain and you may be >screwed<. Let's say you have >this set-up: >Item: <416@hosedsite> >Resp: <417@hosedsite> >Resp: <418@hosedsite> >Now you get <666@newsite>. It has as a references line: > References: <418@hosedsite> >All is well. We can find that. >Now assume you lost (or haven't yet gotten) <418@hosedsite>. How do you >figure out how the item in question is to be filed? Actually, it's fairly easy for this to happen if you consider a special case of the lost-article problem. First easy case: responses to cancelled articles. I've seen several of these in the past few months. Second easy case: restricted-distibution base articles with world-distribution follow-ups. I saw a _very_ interesting string a while back. The base article was locally distributed to someplace my then-server didn't get. The response was to world. The response to that response was local and we didn't get it, and the _next_ response was world again. Every other article, we got. Keep at least the original parent and the immediately previous note. This works much better in cases of limited backtracking ability and no worse in cases where all the information is present. It's not even hard to implement... --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1989 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well. New NNTP connections always available! Send mail if you're interested.
brad@looking.on.ca (Brad Templeton) (11/19/89)
In article <1989Nov18.191428.3783@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes: >Consider the hack a band-aid: it's necessary now, but who wears a band-aid >for their entire lifetime? USENET does, that's who! There are people running software from the late '50s out there, it sometimes seems. I don't mind so much if you muck up your own articles and break the chain. When you muck the references line, you put a broken chain into every followup to your article. It's the worst kind of problem because it multiplies on the net. Each ref-breaker causes a whole new thread. Would it be that hard to hack rn's interpreter for the ref line, so that when it's really long, it deletes from the middle rather than overflowing the buffer? -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
tneff@bfmny0.UU.NET (Tom Neff) (11/20/89)
In article <49584@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >Creating a one line file (for example, under MS-DOS where that can take 4K) >comes under my definition of wasting disk space! Even a 1K file >comes under that definition. However, my second suggestion -- using a single file to contain a list of all "links" -- doesn't waste disk space by any reasonable standard. >The best solution is probably a new file structure, where you simulate >unix directories to a small extent, with files of pointers to the actual >text. (Or even files of message-ids, which are mapped to pointers to the >text.) This approach has its portable aspects, but is not foolproof. For instance, the issue of concurrent expires (or even concurrent posting) can get thorny if everything's in one great file. The host OS simply may not let you get away with it -- or, a nightmarish buffering and locking scheme of OS-rivalling complexity may be needed, with little attendant savings. I think at minimum, an alien implementation should reserve separate files for each active newsgroup. -- "We plan absentee ownership. I'll stick to `o' Tom Neff building ships." -- George Steinbrenner, 1973 o"o tneff@bfmny0.UU.NET
steve@thelake.UUCP (Steve Yelvington) (11/20/89)
In article <49584@looking.on.ca>, brad@looking.on.ca (Brad Templeton) writes ... >In article <14927@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >>>Many other systems don't support links, so if you wish to support >>>crossposting you either have to a) waste disk space, or b) use another >>>file structure. >> >>Trivially untrue!?... if you're porting News over to some other system >>where "real" links aren't supported, just write a one-line file saying >>"-> Link to file ABCDEFG.123" and do the "link" yourself. If this would >>waste too much disk space, you can have ONE file of "links" in each >>newsgroup storage area, and search that list for "linked" articles. > >Creating a one line file (for example, under MS-DOS where that can take 4K) >comes under my definition of wasting disk space! Even a 1K file >comes under that definition. > >The best solution is probably a new file structure, where you simulate >unix directories to a small extent, with files of pointers to the actual >text. (Or even files of message-ids, which are mapped to pointers to the >text.) This is the approach taken by the software I'm using right now: UUREADER (by John Stanley) on the Atari ST, whose operating system in many ways is a 68000 clone of MS-DOS. News items reside in a single spool directory. The reader maintains an index file that looks like this: I+ <49584@looking.on.ca> D A0771.DF X A0771.XF N news.software.b S Just how useful is crossposting? I+ <49591@looking.on.ca> D A0772.DF X A0772.XF N news.software.b S Just how useful is crossposting? I+ <1641@stl.olivetti.com> D A0668.DF X A0668.XF N comp.lang.misc,comp.lang.modula2,comp.lang.pascal S The Olivetti Modula-3 Distribution The I line contains a message status flag (+ in these examples) to indicate whether the article is new/old/marked/deleted. D and X refer to the D file and X file names, munged into a format consistent with GEMdos / CP/M / MS-DOS (8+3, case-insensitive). The UUREADER collates items by scanning the Subject: fields. (In creating the index file, multiple Re: and Re^2: strings are thrown away, so only the root subject field is displayed.) ** The References: line is ignored. ** The user is presented with a list of newsgroups. By pointing and pressing a key, he/she moves into a list of subjects -- not articles. Postings on each subject then can be read in the order in which they were received. Crossposted items (such as the Modula-3 article in the above example) are displayed in each of the named newsgroups, but maintained as a single file on the disk and presented to the user only once. When you read an item and the status changes to old or deleted, it disappears from the displayed message tree in each of the newsgroups. All of this avoids the pitfalls inherent in porting B or C news and rn to a very foreign (and in many ways primitive) system, not to mention the problems with munged References: lines (which is another thread entirely). And it provides what in practice is a very useful user interface. At least it lets me kill whole threads of meta-sci.aquaria with one keystroke. :-) -- Steve Yelvington, up at the lake in Minnesota ... pwcs.StPaul.GOV!stag!thelake!steve (UUCP)
tale@pawl.rpi.edu (David C Lawrence) (11/20/89)
In <14930@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: Tom> The two extreme positions "keep only the latest reference" versus Tom> "keep the whole chain regardless of length" are not the only Tom> workable options. A compromise is possible: keep the root ID and Tom> the last up-to-N parent ID's. Good. And as with your example I think 4 makes a good N, for five total Message-IDs. [Tom, what's with your software? There were several blank header lines in the article that arrived here.] In <49820@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: Brad> Perhaps people should use: Brad> References: <DELETED@DELETED> %i Brad> instead? or <?> or somesuch. This sounds good too. Does anyone have any problems with: References: <a@site> <...> <d@site> <e@site> <f@site> <g@site> or can we start hacking on that now? Dave -- (setq mail '("tale@pawl.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))
brad@looking.on.ca (Brad Templeton) (11/20/89)
In article <14930@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >A compromise is possible: keep the root ID and the last up-to-N parent ID's. This, and other variants are workable to a degree. If we keep enough IDs in the message, and mark the fact that we have done a deletion, then it would be possible for rnews to build the full tree as articles come in, in a special database of the trees. It's bulky, but it can be done. It would only fail if we lose almost the whole chain. Otherwise enough searching should allow us to rebuild it. It's slow and bulky, but it's better than keeping just the parent, where we get completely screwed if the parent never arrives or arrives much later. Actually, an 'ideal' solution is to somehow spot critical nodes in the tree. If we can identify critcal nodes (special message-id syntax) then it is possible to build a tree using only those. Spotting such nodes is difficult. Naturally a first step is to have the posting program, "Is this a reply to the actual article you followed up, a comment on the general topic, or the beginning of a new related topic?" But even this isn't enough, because often a new tangential topic will begin without the poster knowing it. Software can spot this by noting the followup count to a given article, but it can only spot it after the fact. It's hard to change things after the fact, even with a fancy control message, and it may be too late for most readers in any case. (Clearly for the many who followed up.) On some systems they make "creating a new discussion topic" an explicit thing you can do. In some ways it is like USENET, where you can either use postnews or follow-up, but for some reason the distinction blurs on usenet. The now defunct "THE SOURCE" online service had an interesting package called PARTI[cipate]. Like Genie, CIS, USENET etc. you could either follow-up or post a topic-starting article. But they had the ability to hang a topic off of any other topic, thus creating a tree. And they had some staff keep track of global topic areas and keep them understandable. I never got to see it much, as they cancelled the Source 2 months after I joined it! -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
tneff@bfmny0.UU.NET (Tom Neff) (11/20/89)
One thing to keep in mind when designing for reference trees is that ORDER of news delivery is not guaranteed, i.e., the followup may arrive before the parent. That's one reason that the only-the-latest reference approach is risky. At minimum you have to keep an open-minded "cache" for apparently broken trees; or be prepared at any moment to discover that what looks like the "root" is in fact just a branch. With the up-to-N parents approach you implicitly have a few "hooks" on which to hang early or late articles. In the real world there should also be a way of coping with all those NON-superhuman news posting agents which don't make nice with the Refs line. It's not fair to ostracize them from of a discussion except for in-house groups where uniform newsware is a reasonable stipulation. -- "We plan absentee ownership. I'll stick to `o' Tom Neff building ships." -- George Steinbrenner, 1973 o"o tneff@bfmny0.UU.NET
jef@well.UUCP (Jef Poskanzer) (11/21/89)
In the referenced message, tneff@bfmny0.UU.NET (Tom Neff) wrote: }One thing to keep in mind when designing for reference trees is that }ORDER of news delivery is not guaranteed, i.e., the followup may arrive }before the parent. That's one reason that the only-the-latest reference }approach is risky. Not really. One of the points I have failed to get across to Brad is that you have to do this anyway, even if you are using the supposedly easier method of only indexing the "roots". After all, what if a "root" arrives after its first followup? As you say, you have to be prepared at any moment to discover that what looks like the "root" is in fact just a branch. Brad's design is no easier to implement if it is implemented correctly; it's only easier if implemented badly. That makes it a bad design. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef "He that plants trees loves others besides himself." -- Thomas Fuller
perry@ccssrv.UUCP (Perry Hutchison) (11/22/89)
In article <1989Nov17.173753.9790@brutus.cs.uiuc.edu> coolidge@cs.uiuc.edu writes: + perry@ccssrv.UUCP (Perry Hutchison) writes: < part of quotation deleted > + >New (or revised) + >posting programs would prompt for the followup group, if not specified. + >To maximize compliance in the presence of older posting programs, the + >originating transport program (e.g. inews) could check for cross-postings + >without a Followup-To: and insert one, specifying the first-listed newsgroup. + + ACK! Not only do we have a bogus requirement that only one group + contain followups, but we get to engage in gratuitous header + rewriting to enforce it. Who said anything about REwriting headers? I specified the _originating_ transport, i.e. the first one to see the article, i.e. the one on the poster's system; and only the _addition_ of a Followup-To: if it were missing from a cross-posted article. This is a recognition of the fact that a site admin updates one transport, but perhaps N readers/posters, so one must expect the readers/posters to sometimes lag behind. + Crosspostings are a feature, not a bug. They decrease the amount of + time readers have to spend chasing all over the namespace trying to + find the articles they're interested in. I ask again: what problem + exactly are you (those trying to modify crossposting) trying to + solve? One recent example occurred in comp.os.minix. A question regarding minix on an IBM PC was crossposted to comp.os.minix and comp.sys.ibm.pc. I don't remember the topic, but I think the original crossposting was appropriate. The problem was that the followup thread ended up having nothing at all to do with minix, but it was still there because the followup authors weren't editing the Newsgroups. Maybe there is a better way to solve problems like that, but the current situation is certainly not without its difficulties.
coolidge@brutus.cs.uiuc.edu (John Coolidge) (11/24/89)
perry@ccssrv.UUCP (Perry Hutchison) writes: >In article <1989Nov17.173753.9790@brutus.cs.uiuc.edu> I write: >+ perry@ccssrv.UUCP (Perry Hutchison) writes: >+ >To maximize compliance in the presence of older posting programs, the >+ >originating transport program (e.g. inews) could check for cross-postings >+ >without a Followup-To: and insert one, specifying the first-listed newsgroup. >+ ACK! Not only do we have a bogus requirement that only one group >+ contain followups, but we get to engage in gratuitous header >+ rewriting to enforce it. >Who said anything about REwriting headers? I specified the _originating_ >transport, i.e. the first one to see the article, i.e. the one on the >poster's system; and only the _addition_ of a Followup-To: if it were >missing from a cross-posted article. Duh. I was obviously not reading what I was replying to. Mea culpa, and I apologise. This doesn't fix the problem, though. If you don't rewrite headers, then bozos can still crosspost all over the place to their heart's content, as long as _their_ system doesn't have a fixed inews. And they can omit followup-to lines. Of course, the inews at your site could fix new postings, but the damage is done by this point. In any case, I wouldn't fix my inews to do this without an RFC mandate of it, and I'd be busily lobbying against it if someone proposed it. I have a feeling lots of others agree --- it's hard enough to get people to do what the RFCs mandate, much less go beyond them. >+ Crosspostings are a feature, not a bug. They decrease the amount of >+ time readers have to spend chasing all over the namespace trying to >+ find the articles they're interested in. I ask again: what problem >+ exactly are you (those trying to modify crossposting) trying to >+ solve? >One recent example occurred in comp.os.minix. A question regarding minix >on an IBM PC was crossposted to comp.os.minix and comp.sys.ibm.pc. I don't >remember the topic, but I think the original crossposting was appropriate. >The problem was that the followup thread ended up having nothing at all to >do with minix, but it was still there because the followup authors weren't >editing the Newsgroups. This is an inapproprate group problem, IMHO. Yes, it _does_ happen all the time, but that's because many people are careless. In a world without crossposting, the original question might have been multiposted to comp.os.minix and comp.sys.ibm.pc. Then followup discussions might have begun in both groups. That makes things difficult on both interested readers and the original poster. On the other hand, what if the question was originally posted, under your scheme, to comp.os.minix,comp.sys.ibm.pc. The Followup-To: line, by default, would then be comp.os.minix. Then: interested c.s.ibm.pc readers would follow up into c.os.minix, a group they might not even read. To follow the discussion, they have to start reading minix. This is a good thing iff the discussion quickly becomes useful for only one group. Sometimes, like in this case, if does, but in others it never settles down to a one-group issue. Then the proposed solution causes more trouble then it solves. --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1989 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well. New NNTP connections always available! Send mail if you're interested.