ARPAVAX:glickman (06/15/82)
Hmmmm. Let's talk about this keyword/newsgroup issue. I see three different ways to classify and select articles: by keywords, by newsgroups, and by followups. As long as multiple newsgroups are allowed, keywords and newsgroups are practically the same thing. The similarity is more apparent in A news when articles are presented in order of receipt, rather than B's halfway-arbitrary newsgroup order. In A news, the newsgroups aren't as physical: They're just keywords by which you can specify which articles news should show you. Newsgroups in B news are more rigid. They're different than keywords in that it is (or is on it's way to being) more difficult to create new newsgroups. Selection by followups is what notesfiles does: An article and all its followups are grouped together. This makes a lot of sense and is definitely desirable. In my understanding, notesfiles has a two level classification system. The top level is notesfiles, which are comparable to newsgroups. Below that, articles are grouped with their followups. This is a better system than netnews, but I tentatively suggest one modification: Each notesfile can contain another notesfile much like newsgroups. I belive this would make it easier to handle the large volume of articles on the net, but this may not be necessary. bstempleton proposed dividing up the distribution and the content parts of the newsgroup name. That sounds good to me, except it's not really cut and dry. The net part of a newsgroup name isn't just a distribution keyword, it says something about the content. In the same way, the second part of the name doesn't just describe content, it may also determine the distribution of the article. For example, net.general probably goes to more sites than net.rec. By convention, it IS true that the first part of the newsgroup name is the single most important part in the determination of an article's distribution and I can see logically dividing the first part from the rest, it's just important to recognize that the problem isn't entirely simple. I believe these are some of the most important issues for C news/notesfiles and merit some discussion. Matt
ber (06/16/82)
#R:ucbarpa:-160100:harpo:9800004:000:869 harpo!ber Jun 16 01:04:00 1982 I'm optomistic about notesfiles being able to handle the large volume of articles without nesting newsgroups. When an article is defined as a base note and its followups, the number of articles shrinks dramatically. The problem is not too many thoughts, it's that they are too randomly organized. The problem of insignificant news groups is another issue. I wonder if it would be impratical to allow arbitrary creation of newsgroups. The cost of another newsgroup is cheap compared to the cost of discussing its merits. If it were ok just to create it with no discussion, it would either be useful and flourish or it would die. Given automatic archival/removal of defunct newsgroups, how many would there be? Hundreds? Thousands? I would tend to think that the volume of submissions would not increase linearly with the number of newsgroups. brian redman
woods@sri-unix (06/21/82)
Oh, well, here we go again! I apologize if I have missed some of this
discussion, because hplabs, through whom most of our news comes, has been
down for some time. In any case, the problem with allowing arbitrary creation
of newsgroups is that many systems, including ours, have limits as to how long
the options line in the .newsrc file can be. I have already unsubscribed
to as many groups as I can, and cannot cut off any more. This means I have to
endlessly page through many articles that I know I am not interested in.
The more newsgroups that are created, the worse this situation becomes.
Some people have suggested that I do my options line in reverse, i.e.
stating the groups I do want instead of those I don't. Not a bad idea, except
that the number of newsgroups is so large now that I can't do that either for
the same reason, with the additional difficulty that I won't get any new
groups that I may be interested in.
My proposal, which I have stated before, is to have a tree-structured
group system similar to a real UNIX file system, instead of the type we
have now where many groups hang directly off the root when they would better
fit off one of the branches where they could be subscribed or unsubscribed
to en masse. (Case in point: the recent argument about net.sctv .)
I wish to HELL someone (Mark?) would state a policy on new group creation,
bearing these difficulties with the .newsrc file in mind. My own personal
opinion is that NO group should be created until there has been some discussion
on whether the topic really merits its own group, and then the group should
be tacked on as far down the tree as possible. If such an official statement
was in fact made in the last 2-3 weeks while we were cut off from the net news,
I would appreciate someone mailing me a copy. I really hate rehashing this
again and again. Doesn't anyone else have this difficulty with limited options
lines? If so, where the *&%#@ are you during this discussion?
GREG (ucbvax!menlo70!hao!woods)mark (06/24/82)
The tree idea is a good long term idea, but we can't do it until newsgroups with names over 13 characters work. Your subscribe/unsubscribe problem was solved in 2.7 with the ! format in .newsrc. Get yourself a modern version of news and you don't have to ! out 9 zillion newsgroups in your options line, you can say options -n all and just change the : to ! in the newsgroup lines for newsgroups you don't want. Or use the unsubscribe command. You might also want to check and see how many dead groups are in your .newsrc !'ed out, and how many things you can collapse into patterns, for example, you can !all.sf-lovers instead of !net.sf-lovers !fa.sf-lovers. The policy on creation of new newsgroups is that if there is lots of interest (proven by discussion on net.news.group or otherwise) the group gets created. Having too many groups in the world at once is not a consideration - the public just won't stand for it. However, with the large number of groups we have now, the software does need some work to speed up performance. Mark