Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!floyd!whuxlb!pyuxll!eisx!npoiv!npois!hogpc!houxm!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!uiuccsb!essick
From: essick@uiuccsb.UUCP
Newsgroups: net.flame
Subject: Re: Re Flame --> Orphaned Responses - (nf)
Message-ID: <2880@uiucdcs.UUCP>
Date: Sat, 17-Sep-83 22:33:22 EDT
Article-I.D.: uiucdcs.2880
Posted: Sat Sep 17 22:33:22 1983
Date-Received: Mon, 19-Sep-83 00:50:09 EDT
Lines: 82

#R:watmath:-573400:uiuccsb:7600018:000:4005
uiuccsb!essick    Sep 17 12:45:00 1983

Here is the "official" scooby on "Orphaned Responses".

When the notesfile system gets a response to a base note that it
does not have, it generates a foster parent.  This foster parent
has the same unique identifier as the (missing) true parent,
an empty text, and a flag saying that it is a foster parent so
when (and if) the real parent arrives, it will be replaced.

When using the notesfile transfer mechanism (which is batched,
cron-run every so often), responses do not have the title of
the note sent with them. Why should they, since they are linked
to a base note which does have that information?  Notes keeps
track of what it has sent to another machine, what it got
from there, and what originated there and arrived by a different
path. It uses this information to keep a very good idea of
whether to send the base note.  In our local network, we have lost
about a dozen base notes in the last 18 months; not too bad.

Next step is to interface notesfiles with the news system. I've
already explained (about 6 months ago) why there is header
information in the text of the article - the news program didn't
pass on arbitrary headers then; it is much better about that now.

There are 4 types of articles that come in from news to notes.
	@ news-generated "base note"
	@ notes-generated "base note"
	@ news-generated "response"
	@ notes-generated "response"

The two base note types are simple to handle, all the information
is readily available and everything is generally a piece of cake.
When a news-generated response shows up, the news->notes gateway
makes a pretty fair attempt to strip the leading ( it does 
multiple ones too) "Re:" and find the note to which it is a response.
This works pretty well if things arrive in order; when they show
up in the wrong order you now have a response with no base note.
In this case, notes gives up and lets that response be a note.
So far so good, since we still have the title hanging around.

In the last case (a notes-generated "response"), we know for sure
that it is a response and we know exactly which note it is a response
to.  So if we can't find the base note, the thing to do is generate
a foster parent and replace it with the true one later.
Things are still cool since only the local system sees an "Orphaned
Response" message.

What hurts is when the base note never shows up and a discussion 
continues in the responses. Notesfile readers pick up the thread
of the conversation and make a response.  This response goes
out with a "Re: Orphaned Response" in it.  *sigh*  This happens often
enough to be a pain when using the traditional news broadcasting
mechanisms; UUCP definitely does not exhibit FIFO behavior.

Oh yes -- notesfiles NEVER sends the foster parent to another
machine.  The other machine might have the true parent and
if it doesn't it can always generate another foster parent 
there. Ditto for news -- foster parents are never sent there.

Maybe someday I will "cut with repeated irregular blows" the code
so that it tries to hang onto the (possibly) more informative
title that comes through the news system with the notes-generated
response (it itself could be have "Re: Orphaned Response" as a title).

I have many other things to do that are far more interesting and
more rewarding.  As for worrying about saving what "little reputation
I may have left", I think that the notesfile system can and does
stand up very well against the other systems in use (news, vnews
and other variants).  I'll let people try each and make their own
decisions; I've got more exciting things to worry about than
how users who haven't even tried my program think it should be
changed.  If Lee Dickey wants to get a current copy of the program,
use it for a few weeks, and then offer suggestions I'll be glad to 
listen.

Enough public flaming, it's time to go barbeque some chicken and watch
Illinois beat Stanford for our home opener.

-- Ray Essick, University of Illinois
-- ihnp4!uiucdcs!essick     essick.uiuc@rand-relay