From: John Stanley (stanley@peak.org)
Date: Tue Nov 06 2001 - 17:48:45 CST
Charles Lindsey (chl@clw.cs.man.ac.uk):
>And finally, it leads to some confusion (not altogether justified) about
>getting the "wrong article" (actually, it will awlays get you the "right"
>article,
Make no bones about it, if I ask for article X and I get handed article Y,
then yes indeedee bub, I got the wrong article.
> but we should evaluate them to see
> whether they are nearer to giving the "right and expected" results.
The right and expected results are to return article X when X is asked
for, unless it isn't available, in which case return "unavailable".
Brad Templeton (brad@templetons.com):
> If they ask for the original, offer the update.
I.e., give them the wrong article. Planned bugs.
>Namely, if I am reading a thread, and I ask for the parent,
>I should get the thing that superseded or replaced the parent, not an
>error that the article is missing, which is what I get today.
The reason to ask for the parent is to get the context for the message you
are reading. If you get handed a DIFFERENT message, then you didn't get
the parent (*which you asked for*), you got something which may or may not
have any relation to the article you are currently reading. You did NOT
get the context for what you were reading. You are given a changed version
of that context.
> 1) When you browse a thread tree, and an article has been superseded or
> replaced, you should be able to get the successor.
Why? The changed article may have absolutely no relevance to the thread.
It may try to change the context of the discussion, which will confuse
everyone involved. It may advertise green cards.
Of course, you leave out the fact that you WILL get the replacement, just
not in the same point in the thread -- which makes sense since the
replacement occurred at a different point in the thread than the original.
> 2) When an article is replaced with a minor update, it should not present
> again to people who read the original
Define "minor" and then explain why you want to kmake the decision for the
reader, who can make his own decisions quite well, thank you very much.
> 3) It should be possible to have a news: URL work on an article that has
> been superseded or replaced, so that instead of an error message,
> you get access to the current version.
News URLs are inherrently broken, relying on expiration policies at the
reader's server. They are almost immediately broken for any client whose
news server expires quickly. Writing URLs that are almost immediately
broken, and are definitely broken within a few days, is stupid and should
not be encouraged.
There already exist means to write a URL that does not break. This header
is not necessary, and is dangerous because it encourages stupid web
programming.
> The key here is that the function is relatively rare,
And yet, in just the email previous, you claim it would be used a lot.
Pick one. Stick with it.