home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
-
-
- 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
-
-
-