berger@datacube.UUCP (12/15/87)
So whats the story on the Notes software package today?
Is it an dying branch on the tree of news evolution or is there some
creative activity that I'm not aware of?
Is anyone working on improvements and upgrades?
Has anyone made it work in an NFS environment of a shared notes database
that is shared by computers that do not have the same byte orders and
structure alignment characteristics?
Is there improved support for dealing with automatic maintenance of
news and moderator lists as well as the new
comp.mail.maps / pathalias update formats?
We are running version 1.7 of notes has there been any updates?
We really like the notes user i/f but the fact that the notes database
format is not the same as news is making it difficult to keep up with
the evolution of news.
Bob Berger
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
UUCP: berger@datacube.COM, rutgers!datacube!berger, ihnp4!datacube!berger
{cbosgd,cuae2,mit-eddie}!mirror!datacube!bergerrsalz@bbn.com (Rich Salz) (12/28/87)
Bob Berger asked if notes is an evolutionary dead-end. I think so. Too bad, because (at least for local groups) the interface is hard to beat. (For Usenet-wide newsgroups, rn is best.) Part of the reason for this is that it goes against one of the main tenets of the Unix philosophy -- a basically-text database is stored in binary form. This means things like heterogenous NFS sharing takes great pain. If notes is to expand and grow, it's gotta leverage off the work everyone else is doing for regular netnews. The best way for this to happen is for someone to write a "newsnotes" program that reads articles in the /usr/spool/news/comp/sources/unix/123 scheme, but with the aide of the special index file /usr/spool/news/comp/sources/unix/.nnindex to create things like the index page and time-sorted basenote/response chains. If anyone's interested in such a project, I'll help chit-chat, but I'm already way too overcommitted. /r$ -- For comp.sources.unix stuff, mail to sources@uunet.uu.net.
jim@b-mrda (01/02/88)
Mr Underwood, where are You ?????
z@rocksanne.UUCP (Jim Ziobro) (01/02/88)
I disagree that the notesfile file format is a dead-end. For a discussion format dialog it has some real technical advantages over the B-news format method of storing articles. On the other hand it is slightly inferior when handling bulletin board type dialog. Consider that for a discussion the most machine intensive tasks are the article sorting to topics. Ideally this is done once when the article is posted and not each time a group is read like 'rn'. In the notesfile format an article is not expired until there have not been responses for a while. In the B-news format after a certain period the article is deleted whether it is important or not. The B-news expire could be fixed to operate in this desirable fashion but at a significant cost in machine use. If everyone had notesfiles there would be no problem of including massive amounts of text when replying to an article since it would be much more likely that the original text would be at the reader's fingertips. Considering that an open is much more expensive than a read the notesfile format is much better suited for reading agents. The posting operation excluding article sorting is about as expensive in both the notesfile and B-news file formats. One of the ugly operations necessary in any news system is the expire operation. The B-news format ideally would have the big advantage but let us look a bit closer... 1.) To expire B-news articles a history file (and associated dbm file) is read and written but to determine the expiration date each article must be opened and read. Thus: bytes read = #articles x (small) + entire header text bytes written = #articlse x (small) file opens = #articles + 8 file deletes = #expired articles + 3 To expire notes the index files are opened in each notesfile then the text file is copied selectively. Thus: bytes read = entire text database bytes written = entire text database file opens = #newsgroups x 6 file deletes = #newsgroups x 3 Thus B-news expire is proportional to the number of articles while the notesfile expire is proportional to the number of newsgroups plus some factor for the size of the text data. In practice the reading/writing overhead is not great since it tends to happen in large chunks. On an 11/780 with massbus type disks the notes expire operation happened considerably quicker than the B-news expire operation. 2.) If B-news expire happens to run just as you are replying to an article and you are unlucky enough to be accessing an article on expire's hit list then TOO BAD its gone! The notesfile's expire first moves the database to a temporary file thus once a user has opened the database they have access until they are done. In summary: Notes has a relatively high cost of article insertion but that is because it is also usefully sorting the article. Reading agents can operate very efficiently using the notesfile format considering that open calls are generally expensive. In the current implementation (under Unix) the expire operation for notesfile is much quicker than the B-news format. The high article insertion cost means notesfile is most useful where there is some correlation between the articles. Bulletin board type data where any particular article likely goes to many groups is poorly suited to notes. The NYU version of the notes system is well tuned and debugged for 4BSD+ Vaxen. If you are not running the NYU notesfile and you have a BSD derived system then you should be. The NYU version is characterized by the presence of the "universal sequencer key" (l) and occurrences of the name "salkind" in the source. It is ARPA accessible from NYU.EDU. //Z\\ Jim Ziobro
jthomp@tsunami.UUCP (01/03/88)
/* Written 9:38 am Dec 28, 1987 by bbn.com.UUCP!rsalz in tsunami:news.software.notes */ Rich Salz sez: > Bob Berger asked if notes is an evolutionary dead-end. I think so. Too > bad, because (at least for local groups) the interface is hard to beat. > (For Usenet-wide newsgroups, rn is best.) Part of the reason for this is > that it goes against one of the main tenets of the Unix philosophy -- a > basically-text database is stored in binary form. This means things like > heterogenous NFS sharing takes great pain. I sez: We've done Convex-serving-Suns-and-other-Covex's-using-NFS here, it wasn't really too bad. Note (pun?) that these two machines share the same byte ordering, and as such that issue hasn't been addressed. (Horrors, fill that code full of 'htonl' and 'ntohl'.) R$ sez: > If notes is to expand and grow, it's gotta leverage off the work everyone > else is doing for regular netnews. The best way for this to happen is > for someone to write a "newsnotes" program that reads articles in the > /usr/spool/news/comp/sources/unix/123 scheme, but with the aide of the > special index file /usr/spool/news/comp/sources/unix/.nnindex to create > things like the index page and time-sorted basenote/response chains. I've been thinking that a 'nntp'/'rrn' interface would be ideal. With Rich's idea, such a scheme would indeed be thinkable. R$: > If anyone's interested in such a project, I'll help chit-chat, but I'm > already way too overcommitted. I'd like to 'chat' too. I may even be able to commit some weekend time. --jim Jim Thompson Convex Computer Corporation 701 N. Plano Road Richardson, Texas 75081 (214) 952-0200 {uiucdcs,ihnp4,sun,allegra,harvard}!convex!jthomp
berger@datacube.UUCP (01/04/88)
I'm glad to see a little life in this group!
My feeling is that we live in a world of compromise. The news format
may not be the most efficient in some regards, yet it is the most
widely available format and is amazingly standard in a world lacking
in standards.
Yet I like the notes interface and many of the features and I miss
many of the automatic features and compatability with news.
Wishfully thinking (wishfull cause I don't have the time to work on
this myself and I appreciate the time that people do put in), I wish
that there could be a package that could sit on top of news and give
me the best of both worlds. I'm willing to put up with some sacrafice
in performance or machine cycles. Especially if that sacrafice is in
the batch process at nite.
One possiblity would be to use the news database as the baseline and
then add an additional database of indexes and such to support the
notes interface. The bulk of machine cycles to manage these databases could be
spent at the time of news reception / transmission and nitely / weekly
archive times.
Bob Berger
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
UUCP: berger@datacube.COM, rutgers!datacube!berger, ihnp4!datacube!berger
{cbosgd,cuae2,mit-eddie}!mirror!datacube!bergerrsalz@bbn.com (Rich Salz) (01/04/88)
James Zibro points out that news expire is an expensive operation. I disagree. If I use the news article database, augmented with a notes-style index file (in ASCII), then then "newsnotes" expire will be at least as fast as that NYU or 1.7 notes -- scan through the index, build up a queue or articles to unlink, then zap them all: no expensive disk-disk copying, and non of that silly close & compress nonsense. Besides, this runs at 4am; what do I care if it takes one hour or two? Doing individual open calls for each article might be expensive, but I don't care: we're talking about an interactive program, with a human reading the screen. It will be more than fast enough. Storing everything in a flat directory is a lose, both for efficiency in finding notesfile directories, and for non-BSD filesystems: comp.unix-wiza, indeed! Notes's access mechanism is a win. The notes interface is great for local discussion groups; it is only fair-to-middlin' when used on Usenet-wide groups. It's biggest loss is that it doesn't have anywhere near the active development community that news does. As a result, the Notesfile community spends lots of time playing "catch-up": moderated groups was relatively easy, but I'm still waiting for heterogeneous NFS, kill files, and support of cross-posting, checkgroups, and cancel messages. /r$ -- For comp.sources.unix stuff, mail to sources@uunet.uu.net.