Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!osu-cis!tut!tut.cis.ohio-state.edu!orange@greely
From: orange%greely@tut.cis.ohio-state.edu.UUCP
Newsgroups: comp.society.futures
Subject: Hyper-Usenet
Message-ID: <2395@tut.cis.ohio-state.edu>
Date: Mon, 30-Nov-87 04:39:06 EST
Article-I.D.: tut.2395
Posted: Mon Nov 30 04:39:06 1987
Date-Received: Wed, 2-Dec-87 03:30:06 EST
Sender: news@tut.cis.ohio-state.edu
Organization: Swashbuckler Associates
Lines: 189


  The recent discussion of a hypertext Usenet has stimulated me
to submit my own recommendations/ideas for how to accomplish
this.  Since I am neither the most experienced programmer on the
net, nor the most knowledgeable about hypertext, I am welcome to
suggestions/criticisms/flames/snickers.  Here goes...

------------------------------------------------------------
                    Hyper-Usenet: A Proposal.

Definitions:
  Article   - a message posted to Usenet, consisting of the
              message and a header which uniquely identifies it.

  Reference - A text phrase inserted into an article that
              describes a section of a previous article which
              should be included at this point.

  Source    - an article which is referenced by a later article,
              in whole or part.

  Followup  - an article containing a reference to a previous
              article.


A. Overview:
  This article describes a "hypertext" reference mechanism,
designed to replace the current Usenet reference system, which
consists of inserting a block copy of the source article,
identified by a header line stating the ID of the source
message.

Example:
  In article (137@tut.ohio-state.edu), Dave (foo@tut) says:
  >But the mean free path of a positively charged banana is
  >insufficient to explain the ...
(you get the idea)

  If the quotation is long, the followup message is quite
possibly huge (especially in the all-too-common case of a
point-by-point flame), causing heart failure among net-mailers
everywhere.  One solution is to replace long quotes by a
reference to them, and the reader can optionally expand the
reference into the actual text.  A reference is not too terribly
difficult; it need only consist of the ID of the source (in the
example, "137@tut.ohio-state.edu"), the offset of the quote in
the source article, and the size in characters of the quote.
So, the example could (if it actually existed) be completely
described by "@REF(137.tut.ohio-state.edu,xx,yy)", where xx =
offset in bytes into the source article, and yy = the number of
bytes in the quote.  There are problems, of course:

    1.  Articles are not stored by their unique id, but rather
        by a number identifying when they arrived at the local
        site.  This can be overcome by indexing.

    2.  Most sites delete articles a variable number of days
        after they arrive, making any references invalid.  One
        way to solve this is by scanning each article as it
        arrives, checking for references.  Each article
        referenced is then "touched" (creation date set to
        current date).  Optionally, this can be carried out to a
        depth set by the administrator, so that recent threads
        will not be deleted as long as there are further
        contributions.

    3.  A source article might itself contain references to
        previous articles, and the followup may contain all or
        part of the previous reference, as well as text from the
        source.  This is a trickier problem, and will probably
        not be completely solved by me (1/2 :-))

  This is by no means a complete list of problems.  Slow
retrieval times, crossposted articles, arrival of a followup
before the source, reference to an expired article, etc., will
need to be handled.


B. Establishing References:
  The object of this section is to describe a method of creating
the links described above, while not interfering too much in the
normal process of posting a followup article.  To simplify the
explanation, I will first give an example of the current method,
using _rn_.

Example 1:
  (reading article about the amazing property possessed by
  bananas, of always managing to appear underfoot when thrown by
  an uncaring person)

  "F" (submit followup article, including part of current one)

  (program enters your favorite editor, with a file consisting
  of a new header followed by the current (source) article.  The
  quoted text is preceded by a line explaining which article is
  included; each line of the quote is preceded by a ">")

  (submitter edits out the parts of the message not wanted,
  enters a reply, saves the file, and exits the editor)

  (article is posted, and will be echoed across the net)


  Now, here's what *could* be done.  This assumes a custom
editor, but could be accomplished with emacs by writing a custom
library.

Example 2:
  (reading same article)

  "F" (submit followup, machine asks "Use Links? (N/y)".
  Choosing "N" will cause the program to use the above method
  (for compatibility with older news-readers), while "Y" will
  use this method)

  (enter the editor, with two open windows: the first contains
  the header for your reply, and the second contains the text of
  the source article.  You are initially in the top window; when
  you want to include part of the source, you switch windows,
  place a marker at the beginning and end of the block you wish
  included, and execute the "Insert reference" command.  A
  complete reference of the form "@REF(
,,)" is inserted at the current cursor position in your followup. Note that any references in the source are *not* expanded. They are listed in the above format, and are only expanded upon request. Another editor command would be "Expand Reference", which inserted a text copy of the referenced block in the canonical form. Still another would be "Recursively Expand References", which would expand all references in the current article into their text form (this would be handy for an article which contains a large number of small references or where the source contains a large number of other references). The source article is *never* changed, and it should be obvious that this system depends on static sources.) (The new article is saved and posted. When received by a machine, the article is added to the index, and scanned for references. Articles which are referenced have their creation dates updated.) C. Reading articles containing references: This is a little easier. When an article is read, it is first scanned for references, and the referenced text is inserted into the copy made for viewing. The user may optionally supress expansion (for faster display of articles), and may also limit the depth to which reference expansions are carried out (*greatly* increasing speed of display). References may be expanded at any time while reading the article, in the same manner that articles using "rot13" can be decrypted by "X" or "^X". The two above functions, posting followup articles and reading them, can be combined into one program (although putting the editor in might cause size problems on some machines (no kidding)). Speed of retrieval in both functions will depend heavily on the individual machine, making it necessary to include options to limit or ignore expansion. Deleting articles after a certain time (expiration) is a completely different problem, with several possible solutions. The above suggestion is just to open the discussion. Ideas for more efficient methods are welcome. A relevant topic (but not terribly important in this context) is internal referencing, which would have to be handled differently. The only reason I even mention it is that it could be useful in digests. ------------------------------------------------------------ Well, that's my two cents. Any comments? ANY ERRORS/OMISSIONS/FANTASIES/IRRELEVANCIES/ETC ARE DELIBERATE. I wouldn't want anyone to think I had *all* the answers :-) -=- -j "... 'cause they're Vampire Hookers, ...!cbosgd!osu-cis!tut!orange!greely and blood is not all they suck!" greely@orange.cis.ohio-state.edu -- from "Vampire Hookers" (one of these ought to work) (theme song to "Vampire Hookers") ------------------------------------------------------------ Disclaimer: None of the opinions expressed above are, in fact, opinions. The superficial resemblance to what is commonly termed an "opinion" is purely coincidental, and the above message actually consists entirely of line noise. ------------------------------------------------------------