orange%greely@tut.cis.ohio-state.edu.UUCP (11/30/87)
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(<article ID>,<offset to
block>,<length of block>)" 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.
------------------------------------------------------------pesv@enea.UUCP (Peter Svenson) (12/01/87)
I have to react on this, I just have to! this is the most sane thing I have read on this net for over a year. Seriously. But the storage problem .. jeez. What if you did it like this (minor potentially unusable idea) ; Every text written stayed at it's own site, and only references would be sent, I mean ONLY. Then, when you really wanted to see what the original article referred to, you issue an "expand" command, which, like mail or something, fetches all the related articles *for this specific message* and expands everything into a comprehensible form, that THEN can be traversed via hyper-something. Obviously this would require all the world to be connected to one large ethernet, but that where it's pointing at sooner or later anyway, isn't it? Flaming? -- /Peter (turbo) Svenson pesv@enea (UUCP) enea!pesv@seismo.arpa (ARPA) ----------------------------------------------------------------------------- She chuckled. "Don't you wish." The sky tilted, and he saw green horizon. "Twenty thousand meters. I'm going to nuke out."
tower@BU-IT.BU.EDU.UUCP (12/04/87)
In article <16723@bu-cs.BU.EDU> you write: > From: john greely <cbosgd!osu-cis!tut!tut.cis.ohio-state.edu!orange%greely@UCBVAX.BERKELEY.EDU> > > > 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... ... > 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. > Ray Essick's notes software does something like this now. Articles are kept in a chain based (started) with the original article. The chain is only deleted when the newest response has aged. It does save a lot of quoting, when all the articles are generated using the notes interface. Gatewayed USENET netnews has all the old inclusion problems, and chaining of netnews articles can break down (the heuristic used isn't perfect). Note that despite the additional unexpired articles, the disk space used in a notes installation is less than that used in a Bnews installation. enjoy -len