Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!usc!orion.cf.uci.edu!uci-ics!nagel@beaver.ics.uci.edu From: nagel@beaver.ics.uci.edu (Mark Nagel) Newsgroups: news.software.nntp Subject: Re: LIST command and filenames Message-ID: <15207@paris.ics.uci.edu> Date: 21 May 89 00:41:58 GMT References: <157@lib.tmc.edu> <1720@ucsd.EDU> <14701@paris.ics.uci.edu> <161@lib.tmc.edu> <15151@paris.ics.uci.edu> <14014@pasteur.Berkeley.EDU> Sender: news@paris.ics.uci.edu Reply-To: nagel@beaver.ics.uci.edu (Mark Nagel) Organization: University of California, Irvine - Dept of ICS Lines: 68 In-reply-to: phil@east.Berkeley.EDU (Phil Lapsley) In article <14014@pasteur.Berkeley.EDU>, phil@east (Phil Lapsley) writes: |The reason I object to the use of filenames in the LIST command is that |it ties what was a standard protocol (NNTP) to a particular implementation |of netnews. True in some sense, but NNTP is already is "tied" to current news software. The LIST command (ignoring the recent enhancements) returns the active file. The format of the active file is changing in News 3.0 and maybe in C News. The point is that it is up to the individual reading program to request and interpret the particular file(s) it needs to present a useful interface to the user. I can understand the need for a rigid set of protocols for the transfer of news between two sites, but for reading news, it is very important to make the protocol as flexible as possible so that any particular reader has full access to the news library, just as it would if compiled locally. I hope you agree that readers are generally news software dependent. As long as NNTP restricts what a reader may access in the news library, remote readers must offer fewer capabilities than local readers. I'm willing to concede that the LIST mechanism may offer *too* much flexibility, but it is very important that the protocol enhancement offer identical news library views to remote readers that local readers have. I came up with the general LIST idea since two more files were already added to the LIST command. Why not allow any file? Or do the three now available make it possible to write remote readers with the same capabilities os local readers? |For example, let's say my client wants to look at the sys file. The |client issues a "LIST sys" command, and the server dumps out the named |/usr/lib/news file ("sys"). Well, that's neat, until I try to use my |client with some other implementation of netnews that doesn't have a |sys file, or has one but doesn't call it "sys". Worse, I might be |running a version of netnews whose sys file contents/format is different |than 2.11. Oops. Sure, but why? There is already a protocol in place for the sys file. And why might a reader want the sys file? In any event, if the reader *did* want the sys file, it is because the local version of the reader needs it for some reason and presumably the remote version would know what to do once it has it (or what to do if it couldn't find it). |My point is that for anything you want to get via the NNTP server, you |need two documented things: | | 1. A name, which does not necessarily have to be the same as the | name of the file that contains the info. | | 2. A description of the output (contents), which does not necessarily | have to be the same (format-wise) as the contents of the file | containing the info. | |I stress that these need to be documented. If they're not, you're |up a creek when you want to go to different implementations of netnews. And I say that if a local reader must be changed to handle the new news software, then naturally the remote reader must be as well. Until the news software offers a consistent abstract interface to the information it maintains, this will always be true. As I said, perhaps LIST is too general. However, *something* is needed. Any other suggestions? Mark Nagel @ UC Irvine, Department of Information and Computer Science +----------------------------------------+ ARPA: nagel@ics.uci.edu | Six plus six equals fourteen for large | UUCP: ucbvax!ucivax!nagel | values of six -- Dave Ackerman |