Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!lll-tis!helios.ee.lbl.gov!nosc!ncr-sd!greg
From: greg@ncr-sd.SanDiego.NCR.COM (Greg Noel)
Newsgroups: news.admin
Subject: Re: Binary groups need their own hierarchy
Message-ID: <2237@ncr-sd.SanDiego.NCR.COM>
Date: 1 Jun 88 01:50:13 GMT
References: <397@pan.UUCP> <5284@sdcrdcf.UUCP> <22773@bu-cs.BU.EDU>
Organization: NCR Corporation, Rancho Bernardo
Lines: 68

In article <3803@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
>BTW, does anybody else think it's about time to shake the naming tree
>again and create top level binary and source groups with their own
>distributions?  One could even comtemplate a "data" group for all those
>images and whatnot that don't fit into the source/binary dichotomy.

In article <22773@bu-cs.BU.EDU> tower@bu-it.bu.edu (Leonard H. Tower Jr.)
makes an argument to the effect that all the comp.sys groups should be
forced up into their own top-level news group.
>If USENET really decides to go through another renaming spasm, we
>should let comp be devoted only to issues of general technical
>interest.

Although I concur with the point that more top-level news hierachies
should be created, I don't go as far as Len does, suggesting that they
each need their own group.  I do agree with his point that comp should
be focused more on general technical issues.

My fuel for the fire is an observation:  There are seven news categories,
and yet more than 50% of the articles (considered either by count or by
volume) are in a single category, the comp hierarchy.  This argues that
the current division is not as good as could be hoped.

A second observation is that the comp category divides naturally into
three approximately-equal subsets: comp.sys groups, comp.{source,binary}
groups, and everything else.  By this division, comp.{source,binary} has
fewer articles but more volume; the other two are about equal.

This argues that the logical thing to do is divide comp into three top-
level categories.  For the sake of discussion, I suggest we call them
"comm" for the comp.sys news groups (suggested by someone else; I didn't
keep the reference) to suggest commercial systems, "data" for the groups
under comp.{source,binaries}, and "newcomp" for the rest.

My feeling is that the comm groups should indeed be separated out into
their own top-level category; I'm not enamored of the name "comm" but
nothing else springs to my mind.  I'd be pleased if this category would
allow allow news groups where a particular corporate entity was well
represented -- the Amiga news group is an example of this.  I think it's
safe to say that NCR would be interested in something like this.  I would
be happy either with third-party moderation or first-party moderation
with specific constraints to prevent abuse.

As for the data groups, I think the best alternative would be for the
backbone sites to co-ordinate an archive where the sources/objects/data
could be retrieved.  I don't mean to imply that each backbone needs to
be an archive site itself, but if the San Diego area is a good example
of how the rest of the net works, the various "data" groups are already
archived at sites within the region; all that the backbone would have
to do would be to determine where the file was archived and relay the
request to the server who could handle it with the cheapest (by some
metric) cost.  Then machinery would have to be put in place so that
the archives stay current.  This should minimize the cost of making
source/object(/image/stack/...) files available, as they wouldn't have
to be transfered to every site and yet would be quickly (and cheaply)
available upon demand.  As other people have expounded upon the
advantages of archiving, I won't go into that.

I recognize that the second proposal is controversial (well, both are,
but the second is more so), and it's not reasonable to try to do something
that complicated all at once.  However, it might be reasonable to try it
out on a smaller scale; I would like to see that tried.  The existance
and popularity of the current archive servers show that it is possible
to do (for example, NCR will be experimenting internally with a similar
scheme to make tools available to its developers); the problems seem to
be ones of scale and co-ordination.
-- 
-- Greg Noel, NCR Rancho Bernardo   Greg.Noel@SanDiego.NCR.COM  or  greg@ncr-sd