Newsgroups: vmsnet.uucp
Subject: Re: NEWS / DECUS UUCP Integration
From: jeh@cmkrnl.com
Date: 24 Jul 92 13:05:43 PDT
Distribution: world
Organization: Kernel Mode Consulting, San Diego, CA

In article <1992Jul24.110458.4548@ecl.psu.edu>, fenner@jazz.psu.edu (Bill Fenner) writes:
> I was quite surprised when UUCP claimed that it wanted to move
> my news_manager directory, or things wouldn't work correctly.  In fact,
> when I told GENERATE_CONFIG not to move the news directory, it refused to
> create a new CONTROL. file.
> 
> This is the kind of behavior that makes it really easy for people who don't
> have a clue, but quite difficult for people who know what they're doing and
> happen to do it differently.  I'm willing to modify NEWS_RNEWS.COM for my
> setup.  I'm not willing to modify my NEWS setup to satisfy UUCP.

The 2.0 manual goes into some detail as to why news_device (the "news item
files" disk) is a much better place for the news_manager tree than uucp_disk
(if these are separate disks).  To summarize, if these are separate disks, and
if news_manager is on the uucp disk, you can get into a deadlock situation re.
disk space.  If news_manager is on the news disk, you can't (with the new flow
control mechanisms built into 2.0, thanks to Mark Pizzolato).  Details are in
the documentation.  Do you have a compelling reason for needing it set up the
old way?

> I also find it annoying that the NEWS executables were placed in UUCP_BIN:
> for me.  I already have NEWS installed, now I have to go through UUCP_BIN: and
> remove all the NEWS files individually from there.

...and a lot of people found it annoying to have all of the exe's for the 
package in one place, EXCEPT those for news (but NOT excepting the images that
are provided for news integration).  This is a matter of taste and any
decision we make is going to annoy some folks, for reasons that boil down to
"I'd prefer it the other way".  Sorry.  

> Please, folks, for the next release, try to consider the person who wants
> his NEWS seperate from his UUCP.  

And what about the person who wants his NEWS combined with his uucp? 

I suppose we could have a NEWS_BIN logical that by default was equated to
f$trnlnm("UUCP_BIN") but which could be redefined to NEWS_ROOT or wherever.
However we then have the problem of deciding just what is a "news executable"
(and therefore deciding, and, when writing code, REMEMBERING) which logical to use to refer to what).  This was my
idea behind moving everything to uucp_bin:.   Clearly news.exe and nntp*.exe
would belong under news_bin, but it's less clear for newsskim.com (which
originated with Geoff Huston but has been completely rewritten for uucp), and
even less clear for news_rnews.com and uux_rnews.exe...  Do we classify things
by uucp - vs - news (the last two have feet in both camps), by origin (only
news.exe and nntp*.exe, and it seems silly to put them off by themselves), or
what???  Putting everything under uucp_bin makes it lots easier to remember 
where things are. 

Another issue is file and directory protection.  All executables and command
procedures -- including news-related ones -- in the package should have the
same protection:  world-readable directory and files (after all, anyone in the
(literal) world can obtain the stuff through DECUS, so it makes little sense to
lock it down tighter than that on one machine), but this is markedly different
from the protections that are appropriate for the big indexed files in
news_root (which is where news.exe used to live). 

The point of all of this explanation is not to browbeat you into agreement, but
to demonstrate that we did not make these decisions arbitrarily -- we had
reasons.  If you have compelling reasons for other arrangements, let us know;
we promise at least to listen. 

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet Working Group, and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
Xref: sparky vmsnet.uucp:616 comp.os.vms:13016