[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LYNX-DEV Re[2]: reorganizing the lynx-archive
From: |
Robert Bonomi |
Subject: |
LYNX-DEV Re[2]: reorganizing the lynx-archive |
Date: |
Fri, 8 Nov 1996 19:02:09 -0600 (CST) |
+ Date: Fri, 8 Nov 1996 12:26:21 -0800
+ From: address@hidden (David Combs)
+ To: address@hidden
+ Subject: Re: LYNX-DEV Re: reorganizing the lynx-archive
+
+ More on same (reorganizing the archive):
+
+ Also, people like me who submit ONE email with THREE (say)
+ subjects discussed, must be convinced to submit three
+ SEPARATE emails (which will make them think, are each
+ of these really important enough to submit and subject
+ each group-mbr to).
+
+ QUESTION: "TRN" turns each thread, somehow, into a branching
+ tree. On what basis does it decide on starting a new
+ branch (sub-thread). Is it just the subject line?
TRN makes -no- use of the subject line, in point of fact.
It uses the 'article numbers', and the 'references' header line
to do its 'magic'. Any 'folllow-up' article contains a header
with (at least) the ID number of the =immediate=predecessor=
article to which it is following up. TRN merely tags that new
article as a child branch of the parent. Thus, each -independant-
response to an original posting starts a _separate_ branch.
OTOH, a response, then a 'response to the response', and a
reply to the response to the response, and a rejoinder to the
reply to the response to the response, string out as subsequent
elements in a single thread.
Note: trn has a _lot_ of stuff in it to handle the situation where the
reply-to-the-response arrives before the response; what to do if an article
shows up claiming 'parentage' that trn thinks are two un-related (bastard??:)
threads, etc. _None_ of those smarts are needed in this case, since the
re-mailer *has* an "authoritative" list, and _always_ sees the elements in
a 'thread' in order (by definition :).
+
+ QUESTION: would it be worthwhile to have SUB-subjects
+ down WITHIN the email (like in a book: chapters, sections,
+ etc), and maybe someone (not me) hack hypermail (or trn!!!)
+ to make it work with this?
This could be done, _relatively_ *trivially*, by hacking the re-mailer to do
some more massaging of the 'Suject:' header line. It would need
to do the following things:
1) prepend "LYNX-DEV [i.d.-number]" to the Subject line -before-
sending it out.
2) When a message -arrives-, with a "Re: LYNX-DEV [i.d.-number] {blah blah}"
Subject header, *remove* the "LYNX-DEV" label that occurs to the
_right_
of the 'Re:' .
3) if there is more than one 'Re:', remove all but the first one.
4) optiion: May want to 'prune' the 'list' of ID numbers (to keep the
subject line 'managable', to just the current id, and the one of the
message being referred to.
Example:
new article header: LYNX-DEV [47] Trouble Compiling on MVS.
somebody responds header: LYNX-DEV [54] Re: [47] Trouble Compiling on MVS
a reply to that header: LYNX-DEV [56] Re: [54][47] Trouble Compiling ..
(or, compressed) LYNX-DEV [56] Re: [54] Trouble Compiling on MVS
somebody responds to the original,
apparently _not_ seeing the prior
response header: LYNX-DEV [80] Re: [47] Trouble Compiling on MVS
It is now a 'nothing' operation to string things together into 'threads'.
+
+ OR: how about this idea:
+ For producing manuals, letters, etc, I use the old CMU program
+ "Scribe" (greatly enhanced by people who took it over
+ from Brian Reid), which has a nifty "index" facility,
+ to create the back-of-the-book index.
+
+ (Other such programs have similar facilities).
+
+ So, in Scribe you can create your own macros, eg @myIndex(word, description),
+ to use like this:
+ This is done by foo, a neat program.
+ becomes
+ This is done by @myIndex(word="foo", description="Here we mean the
+ foo PROGRAM, not the foo ATTRIBUTE."), a neat program.
+
+ Stupid example. Anyway, the "foo"-listing in the index will
+ have that description stuck out to its right, followed by
+ the page numbers it appears on.
+
+ QUESTION: does the above concept lead to any IDEAS about
+ how FUTURE email could be structured (it is too late probably
+ for the EXISTING stuff -- way too much to do)?
Probably the most viable way to do this is with a 'structured' arrangement
to the *body* of the email. This 'structure' can be automatically enforced
by the re-mailer, returning any 'non-conformant' messages to the sender,
ALONG WITH info on how to format a 'correct' submission.
I see several 'classes' of material on this list:
1) 'configure/compile' problems -- e.g. "I'm installing on FOO v. 89.543,
and make dies with the following errors: <blah blah blah> "
2) 'design issues', or 'forward plans' -- e.g., "using GNU autoconf"
3) "patches" -- feature adds, bugfixes, etc.
4) "Anomolous behavior" reports -- e.g. "things don't display right when
I look at http://foo", or "lynx crashed when I did ....."
5) "wish list" -- desirable features for future implementation.
6) Resources -- web sites, the LYNX enhanced pages, "browser.org", etc.
note: there *is* some 'blurring' between 2) and 4). discussion of an
existing (real) problem tends to lead to 'what should we do about it'
discussions. similarly, design issues may lead to patches. :) One
does -not- want to segrate by class, therefore.
Suggest that the following is relevant to any/all articles.
LYNX version:
Hardware, O/S:
Message type:
'LYNX version', and "Hardware, O/S' are critical for dealing with 'install
problems' and/or 'bug reports'. Some design issues and/or patches are
specific to particular environments, others apply to 'any or all'.
There is an -added- benefit to requiring people to specify the -version-
in a 'machine-readable' form. If someone is filing a 'bug report', and they
are running an old version, an _auto-response_ can be generated explaining
those facts, and pointing towards location of a current version.
I'd propose the following for 'message types':
'install problem'
'development plans'
'patches'
'bug report' and/or 'problem report'
'resources'
'wish list'
'other' and/or 'misc.'
ADDITONAL COMMENT: *anyone*, who is -not- a subscriber to the mailing-list,
and who SENDS MAIL *TO* it, should get an auto-response telling them about
the archives, and that they should check _there_ for responses to their
problem, as they *may*not*get* an individual response. I, personally,
know of three people who submitted problems, per the directions from
lynx's 'fatal error' handler, and never heard so much as a 'thank you'
for their efforts. *NOT* good 'public relations'!
;
; To UNSUBSCRIBE: Send a mail message to address@hidden
; with "unsubscribe lynx-dev" (without the
; quotation marks) on a line by itself.
;
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- LYNX-DEV Re[2]: reorganizing the lynx-archive,
Robert Bonomi <=