home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Der Mediaplex Sampler - Die 6 von Plex
/
6_v_plex.zip
/
6_v_plex
/
DISK3
/
DFUE_11
/
SQLNK120.ZIP
/
SQLINK.DOC
< prev
next >
Wrap
Text File
|
1993-04-22
|
16KB
|
417 lines
SQLink Version 1.20
Squish message base MSGID/REPLY linker
For MSDOS and OS/2 systems
____________________________________________________________
David L. Nugent & Unique Computing Pty Ltd.
Copyright (C) 1992-93
All Rights Reserved.
PLEASE NOTE!
In using the enclosed software you do so entirely at your
own risk. The author and/or distributors are not responsible
for any loss or damage as a result of using this product,
consequential or otherwise, and will not be liable for any
circumstances arising out of its use and the only function
that is guaranteed to work as advertised is that this
software and/or documentation will occupy disk space.
This product is FREE FOR ANY USE and may be distributed
without consent for that purpose. Commercial distribution,
including sale IN ANY FORM is prohibited.
ABOUT SQLINK & REPLY LINKING
----------------------------
SQLink is a supplement to Scott Dudley's Squish conference
mail processor. It is a direct replacement of the SQUISH
LINK function, and instead of using the more traditional
reply thread linking by subject, SQLink uses "true" reply
linking, taking advantage of the fact that Squish format
areas can retain up to 10 reply chain links instead of only
one as with other formats used by some other Fidonet
compatible Bulletin Board and messaging systems.
The fact that a message can be linked to its "true"
original makes conversations in conference mail easier to
follow directly from the original post to its direct
descendants (the replies to the original), replies to those
individual replies etc. It can be readily demonstrated that
any conversation thread is in the form of a tree, thus:
Original
Message A ------ Reply A.1 -->
|
+--- Reply A.2 ------ Reply A.2.1 -->
| |
| +--- Reply A.2.2 -->
|
+--- Reply A.3 ------ Reply A.3.1 -->
| |
| +--- Reply A.3.2 -->
| |
| +--- Reply A.3.3 -->
V
Within a local message area, Maximus CBCS already maintains
"true" reply threads. Second and subsequent replies to any
individual message gets added to the existing replies, as it
should be. However, in wide area conferencing systems, such
as echomail, this direct linkage information gets lost,
since any reply linkage information is effectively gone once
it is scanned and packed for transmission to another system.
The traditional answer to this was to use the subject line
(or part thereof) for reply linkage, so that messages with a
common subject would appear to be part of one linear reply
chain. This requires that all participants in that
particular conversation retain the same subject (even if it
is no longer meaningful), but does not prevent other
spinoffs from the same thread, or someone entering an
entirely unrelated message using the same subject line, from
being confused into the same thread. So, while this method
works adequately (sometimes), it's really just a work-around
invented because it was "better than nothing".
The problem in true reply linkage is twofold; first,
messages must be uniquely identified in a similar way across
all systems to which it travels. Secondly, when a message is
a reply, it must retain not only its own unique identifier,
but also the indentifier of the original message.
A method of doing this, now fairly widely supported in
Fidonet technology software and becoming more common every
day, is using two "control" lines within message text which
are normally hidden from view when reading. These are
^aMSGID (message identifier) and ^aREPLY (reply-to
identifier).
The usual format is:
^aMSGID: <origin_address> <8_digit_hex_number>
and
^aREPLY: <MSGID_string_of_original_message>
Whether this format is strictly adhered to or not, SQLink
does not care. It only matters that whatever follows the
"^aMSGID:" is completely unique, and never duplicated (for
this reason, the MSGID would be very useful as a duplicate
detection scheme once its use becomes universal). One other
important thing about MSGID lines is that they will only
ever be added and generated in messages which originate on
the local system - almost always at the time it is created.
They will not be stripped, changed or normalised by any
systems that the message passes through. (Refer to FTS-9 for
the full MSGID/REPLY specification document).
In linking replies, SQLink threads replies using these
special control lines ONLY. Because not all software
generates and uses these lines, the scheme is not yet
perfect, but in most cases it will certainly be adequate.
Unfortunately, not many message editors support multiple
forward (reply) links well, if at all; however, being early
days for the Squish format, which specifically does support
this, means that it opens the possibility for software, such
as SQLink (and MaltEd) to do that in the future. Certainly
Maximus itself will display multiple forward links where
they exist, and fully supports generation of MSGID/REPLY
control information.
You will find that in some conferences, using MSGID/REPLY
information will not be useful, especially in special cases
such as gated newsgroups or areas where the software
predominantly in use does not support MSGID/REPLY
information. You can disable SQLink from looking at those
areas, and optionally allow "SQUISH LINK" to take care of
them instead. (See below)
PROGRAM USAGE
-------------
First, note that two executables are supplied; SQLink.exe is
for MSDOS systems, SQLinkP.exe is for OS/2 systems. Both are
16-bit, and so are compatible with 8088 systems under MSDOS,
and can be run under OS/2 1.2 and later. The protected mode
OS/2 version is HPFS compatible.
The simplest use of SQLink is to run it in the same area as
your SQUISH.CFG with the "-all" switch. It will process
all echomail areas (marked by the "EchoArea" keyword) and
link reply threads.
In reality, you will probably only do this once. Thereafter,
you would maintain the reply links when tossing inbound
mail. You should also note that existing reply links will be
automatically maintained even after a Squish area is tossed
to or messages culled by age after using SQPACK (and Renum
days). Messages in Squish areas are not threaded by an
arbitrary "message number", and all messages maintain an
internal identifier which stays with that message while it
still resides in your message base. It is therefore only
necessary to re-link an area to remove obsolete links to
messages which no longer exist, and add references to
messages newly added to the area.
The format of the SQLink command line is:
SQLINK [-c file] [-a file] [-f file] [-n] [-all] [-k] [areas]
All command line arguments are optional. If the environment
variable "SQUISH" is set, the "-c arg" option may be omitted
and a file if called "SQUISH.CFG" does not exist in the
current directory, the file to which this variable points
will be used (this emulates the same behaviour as Squish
itself).
Switches:
-c <squish.cfg> Specifies the path, relative or
absolute, of your SQUISH.CFG (it can
in fact be any name, but it should
be a valid squish configuration
file). Note that only "EchoArea",
"NetArea", "DupeArea" and "BadArea"
lines are read from this file, and
all other lines are ignored. SQLink
MUST find a valid squish
configuration file in order to run,
except if the -a switch is used.
-a <areas.bbs> Specifies the path of a text file
which uses the AREAS.BBS format for
message area specification. This may
be used as an alternative or
suppliment to reading a file in
SQUISH.CFG format. Only areas
preceeded by the '$' which indicates
that it is in Squish format will be
processed. Note that it is quite ok
if both squish.cfg and areas.bbs are
specified and used. Duplicated tags
are automatically eliminated.
-f <echotoss.log> An optional path to a file
containing echomail tags. Used in
combination with SQUISH.CFG (and/or
AREAS.BBS), this limits Sq-link's
activity to just those areas. SQUISH
(using its -f option), Maximus and
many editors produce such a file.
-n Requests that SQLink link the
the netmail area, even if its area
name is not found in ECHOTOSS.LOG.
The command "SQLINK -n" links all
Squish format netmail areas.
-k This option only has meaning if the
-f option is used to specify an
echotoss.log file. It is used to
either automatically delete the
echotoss.log file after processing,
or, if not all areas described in
that file have for one reason or
another been processed, then only
the areas actually linked have their
tags removed from this file.
-all This switch tells Sqlink to link all
areas found. This was the default
behaviour with previous versions of
SQLink.
[area ...] One or more area tags which are to
be linked. This may be combined with
the -f switch to force linkage of
some areas even though they are not
specified in the echotoss.log.
As SQLink processes squish areas, it displays area
statistics as follows:
SQLink; Squish MSGID/REPLY Linker [MSDOS]; Version 1.20
Copyright 1992-93 by David Nugent & Unique Computing Pty Ltd.
Linking MUFFIN Read 0023/0425 Link 0121/0398
^ ^ ^ ^ ^
| | | | |
+-- Area tag A B C D
A> Reset links These are messages where reply link
information has become obsolete;
where links have been specifically
cleared because they no longer exist
(you should have a large number of
these when you first run Sq-link).
B> Total read This will agree with the total
number of messages currently in the
area.
C> New links Messages where new links have been
added. Again, the first run of
SQLink on an area will see a large
number of these.
D> Linked messages This number represents the total
number of messages containing
message link information (some of
which may not be linked anyway). In
deciding whether to use true reply
linking or not for an area, you
should look at this statistic and
compare it against B to see how
predominate reply link formation is
in that conference.
SUPPRESS LINKING
----------------
As has already been mentioned, it is sometimes not worth the
time and trouble to reply link particular areas using reply
link information. You can prevent SQLink from linking those
areas by using a "-nl" (no link) switch on the corresponding
EchoArea line in your SQUISH.CFG. (There is currently no
way to suppress linking areas which are specified in
AREAS.BBS format).
Note that this is NOT a switch that SQUISH will understand,
but it is nevertheless ignored by SQUISH and will not affect
the way it works in any way.
Squish will not link a BadArea or DupeArea, although if one
of these is found in a given ECHOTOSS.LOG, the tag will be
removed if it needs to be rewritten.
EXAMPLES
--------
Most mail processing will see conference areas re-linked
after receipt of mail. The following batch file fragment
shows an example of how you might blend in SQLink to your
existing setup:
"One pass" mode:
SQUISH -cSQ.CFG -fTOSS.LOG IN OUT SQUASH
SQLINK -cSQ.CFG -fTOSS.LOG -k
if exist TOSS.LOG SQUISH -fTOSS.LOG LINK
if exist TOSS.LOG del TOSS.LOG
This will do a one pass toss, scan and pack, followed by a
link of all areas which SQLINK is able to link, and if any
areas remain to be linked, they will be "subject linked"
using that facility in SQUISH.
You should be able to adapt this to almost any setup
involving squish.
NOTES
-----
The -Widgets switch can be slow.
CREDITS
-------
Squish and Maximus-CBCS are copyright Scott Dudley.
Thanks (again) to Scott, the inventor of the very robust and
flexible Squish message format, which makes this program
possible without the need to invent kludges or work around
shortfalls in the design of the message base format itself.
AUTHOR
------
Can be contacted:
FidoNet 3:632/348@fidonet
IntlNet 58:4100/1@intlnet
Admin 33:300/6@admin
InterNet/ACSNet davidn@csource.oz.au
BBS +61-3-792-3507, +61-3-794-7949
Surface mail:
David Nugent
Unique Computing Pty Limited
PO Box 352
Doveton, Vic, 3177.
Australia