phil@east.Berkeley.EDU (Phil Lapsley) (05/21/89)
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.
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.
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.
(Private flame: this is why I think the so-called "finger protocol"
is bogus. You get back a bunch of strings that cannot be parsed
by a machine because their is no standard for their format).
Phil Lapsley ...!ucbvax!phil phil@ucbarpa.Berkeley.EDUnagel@beaver.ics.uci.edu (Mark Nagel) (05/21/89)
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 <file> 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 <file> 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 |
phil@east.Berkeley.EDU (Phil Lapsley) (05/21/89)
In the referenced article, Mark Nagel writes: > [...] but NNTP is already is "tied" to current news > software. The LIST command (ignoring the recent enhancements) returns > the active file. But the format is documented, at least to some degree, in RFC 977. With the current news software, it happens that this description corresponds to what's in the active file, so it's easiest just to slam the active file out over the socket. If the active file were to change, you could, if you wanted, massage it to look no different to the client. (In fact, a strict interpretation of the RFC would require that you do this; but let's not let narrow legalistic interpretations stop progress). > As I said, perhaps LIST <file> is too general. However, *something* > is needed. Any other suggestions? I have no problem with adding more items to the LIST command; I just want them to be better documented than "This command returns whatever happens to be in an arbitrarily named file on the server." :-) That was the thrust of my earlier article. Phil Lapsley ...!ucbvax!phil phil@ucbarpa.Berkeley.EDU
rsalz@bbn.com (Rich Salz) (05/21/89)
In <14026@pasteur.Berkeley.EDU> phil@east.Berkeley.EDU (Phil Lapsley) writes: >I have no problem with adding more items to the LIST command; I just >want them to be better documented ... Okay, here's one I'd like: LIST descriptions returns a set of lines formatted like this <newsgroup name> <whitespace> <text> this is intended to provide a one-line description of the "charter" of all newsgroups that are available on the server. It is not required that this be an exhaustive list, but it is recommended. /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
ulmo@ssyx.ucsc.edu (Brad Allen) (05/25/89)
> As I said, perhaps LIST <file> is too general. However, *something* > is needed. Any other suggestions? Yeah. NNTP is for, eh, let me unplug my ears: Transfering Messages. Ahh. Well, turn these Messages into Objects, put on a few other needed items (e.g. version control, object types, definitions of objects), and suddenly your files are alive and humming. The protocol should be redesigned, enhanced, etc., not turned into some strange growth form where the middle is a bunch of dead but necessary structure. Remember, not everyone uses Unix.
ulmo@ssyx.ucsc.edu (Brad Allen) (05/25/89)
In article <1736@papaya.bbn.com> rsalz@bbn.com (Rich Salz) writes: > Okay, here's one I'd like: > LIST descriptions > returns a set of lines formatted like this > <newsgroup name> <whitespace> <text> ^^^^^^ This could be replaced with <Message-ID>. You would read that article for information.