Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!agate!saturn!ssyx.ucsc.edu!ulmo From: ulmo@ssyx.ucsc.edu (Brad Allen) Newsgroups: news.admin Subject: Re: Permanent Postings Keywords: Files Common Questions Space Time Savings Message-ID: <6199@saturn.ucsc.edu> Date: 2 Feb 89 03:37:40 GMT References: <6022@phoenix.Princeton.EDU> Sender: usenet@saturn.ucsc.edu Reply-To: ulmo@ssyx.ucsc.edu (Brad Allen) Organization: not affiliated with UCSC Lines: 51 I have thought this was a badly needed feature of USENET ever since I learned that news doesn't stay around forever four years ago. I was ready to suggest this too. Here were my rough ideas, for USENET: Every group would not only have a moderator, but also a maintainer of the database of current common reference/history/whatever it should be called (what is a good name for this stuff??) In addition to this, I was wanting to suggest adding continuous-message- hierarchy features to USENET which would keep every current message organized to some extent. Off the top of my head, I could say that new topics (branches, threads, subjects, whatever you call it) may at first be unapportioned or placed in the static tree hierarchy by the user, but later this positioning could be modified or maintained by the reference moderator. Also inherent in the idea in the last paragraph are a few more things: author of links; control messages which update links; version #s of links, messages, etc. hopefully using some deterministic algorithm which can smoothly take care of the problems of out of order lost duplicates etc. I'll note that a lot of this is already in place, such as Reference: lines and such, but that this would need to be expanded and modified yet further for elegant functionality ... > a set of files, or "permanent postings" to each newsgroup, which This is somewhat already doable. All that would have to be done is modification to the rules to allow for this moderator of permanent postings, and then use the same Supercedes:, Approved:, etc. constructs as used in comp.mail.maps and elsewhere. > After the start-up time, which admittedly would be difficult, > changes to "permposts" could be in the form of diffs, just as some The impitous for diffing news is obvious. However, version control would have to be implemented; a rule would be declared: you may only obtain version C by appling diff B on posting Y, and not by applying it on posting X; each diff would have to explicity state these things. It all seems pretty easy to me. more impractical semantic mumblings from brad allen P.S. For an ok implementation of a tree message system, you can call XBBS (NOT Xenix BBS!), 1200/300bps, +14084764945, 4 lines, crashes frequently (buggy as hell), but it's there and it has documentation. This is a closer relative to Stuart II (now defunct) than Magpie is.