Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site uw-beaver Path: utzoo!decvax!wivax!linus!allegra!eagle!harpo!floyd!vax135!cornell!uw-beaver!jim From: jim@uw-beaver.UUCP Newsgroups: net.followup,net.news Subject: Re: 123456789012345678901234567890123456 - (nf) Message-ID: <650@uw-beaver> Date: Wed, 1-Jun-83 13:11:57 EDT Article-I.D.: uw-beave.650 Posted: Wed Jun 1 13:11:57 1983 Date-Received: Tue, 7-Jun-83 23:38:42 EDT References: <5326@watmath.UUCP> <280@qubix.UUCP> <337@spanky.UUCP> Organization: U of Washington Computer Science Lines: 121 I talked to Ray Essick at the University of Illinois, who wrote the notesfile system, a while back about the news to notes interface. He wrote the interface a long time ago (as usenet goes) and doesn't have the time to work on it now. Isn't there anyone else out there who runs notes and would be willing to put the effort into bringing the interface up to the current standard? I trust Ray won't mind my reproducing this exchange here. From: Jim ReesSubject: Some suggestions to make notes friendlier To: essick@uiucdcs I am very impressed with notesfiles. It is far superior to readnews for reading the news. But although the user interface is nice, the interface to the news system leaves much to be desired. My main complaint has to do with handling of the "References:" field. Notes doesn't generate one. Our news system (not vanilla readnews) depends on this field to match up followups to what you call the base note. If the field isn't there, we get the equivalent of an orphaned response. As you know if you've ever used readnews directly, these can be pretty annoying. I find it ironic that one of the big advantages of notesfiles, its ability to keep base notes and followups together, is lost to users of news when the followup comes from a notes system. Not only does notesfiles remove the important base note info from followups, it inserts its own distracting info into the body of the article. This shows up as two lines of garbage at the beginning of every article: #N:uiucdcs:23300026:004:2035 uiucdcs!essick Apr 25 14:00:00 1983 Can't these be put into the header as a special field? For example, they could be turned into: Notes-Header1: #N:uiucdcs:23300026:004:2035 Notes-Header2: uiucdcs!essick Apr 25 14:00:00 1983 and put in with the rest of the header. Then they could be easily weeded out by news reading programs. I realize that this might create compatibility problems with old notes systems, but I think it is a little unfair of you to drop my reference information then expect me to pass yours along. Why are subject lines shortened so much by notes? It is a little annoying to me to see a subject field something like this: Subject: Re: Need a foo bar adaptor for my Unix version - (nf) If the reference info was available, this wouldn't be much problem, because I could just look at the subject of the base note. But the reference info is lost, so I don't see the subject field except in its truncated form. Whew! I didn't mean to be so long-winded. If you've gotten this far, my thanks for reading. I look forward to your early reply. Jim Rees University of Washington >From ihnp4!parsec!uiucdcs!essick Tue May 10 11:29:44 1983 To: parsec!ihnp4!uw-beaver!jim Subject: Some suggestions to make notes friendlier Thanks for the suggestions; the notes/news interface is probably the most ``hacked'' part of the package. Back when I was writing this stuff (fall '81/spring '82), the only news software I had was A-news. Of course A-news left many things to be desired, including the lack of extra header fields. Going from news -> notes isn't too hard. Since I used the `A' format, all that needed doing was to parse some well-defined fields. Going from notes-> news was tougher. My first problem was with the article id's; notesfile article id's are longer than the news id's. This is because each notesfile has it's own "unique integer" counter and the system wide article id had to include the name of the notesfile (actually another "unique integer"). A-news and B-news both didn't like id's longer than 14 characters so I tried base conversion and stuff. Neither program liked that so I gave up and tried a separate header line. A-news gateways should pass header lines (since they wind up in the body of the article). B-news didn't pass unknown headers when I worked all of this out. Bummer. Since all sorts of bad things (duplicate articles and such) would happen if one of these articles crossed a B-news system that dropped the extra header line, I stayed with the information in the body of the article. Probably the most "correct" thing to do is to rewrite the notes/news gateways. But I don't have the time.... When I first started the project, articles were limited to 19 lines of 79 characters, there was no networking, and we were trying to make it fit our local environment (11/40, small disks, not much spare CPU time, big penalty for opening/closing files). You can see what has happened to it since then. If I had my 'druthers I would rewrite the entire package, figuring that you always throw the first one away. I've even drawn out some of the data structures for a new implementation (as opposed to a modification to the current one) which address some of the problems that both news and notesfiles have run across. I don't know when/if I will ever do this; there are other things that I want to do and still more that my research advisor wants me to do. My recent work with the notesfile code has been to consolidate what I have. I don't think you can beat the code in an environment what I have. As a development tool (team-communications, log-keeping, etc.) it is tough to beat. It is also very good in small subnets of USENET. We use it exclusively here and have no problems around campus (about 15 Unix machines running the code). Adapting the current code to a large net (like all of USENET) is going to be tough; it will be easier to write something new which combines the advantages of notesfiles for structure and the parts of News that make it work well in the large environment. Enough for now, I really should be off studying for my finals. I always appreciate constructive criticism and try to incoporate good suggestions into the code. If you hae any ideas, I'll listen to them. -- Ray Essick, University of Illinois