Text 2323, 104 rader
Skriven 2012-08-14 11:09:35 av mark lewis (1:3634/12.0)
   Kommentar till text 2292 av Paul Quinn (3:640/384)
Ärende: Quoting problem
=======================
 ml> they won't be there... QWK simply doesn't do FTS-0009 and no QWK
 ml> reader can be FTS-0009 compliant

 PQ> I give up.

i can't say that i blame you :)

 PQ> I've wasted a few hours on this this morning, after a few 'but
 PQ> first' jobs.  

trimming that "honey do" list down, eh? ;)

 PQ> During tests, SLMR blew itself away.  It started running out of 
 PQ> memory all the damned time, after I downloaded a fresh QWK packet 
 PQ> from my BBS.

i haven't heard of SLMR doing that... what environment are you trying to run it
in? the biggest problem that SLMR has is a 200 lines per message limit... posts
longer than that can only show the first 200 lines...

 PQ> Then, I tried Durango but it wouldn't even install since it's an 
 PQ> old 16-bit Win ap.

yeah...

 PQ> While keeping MultiMail in mind as a second-to-last resort (the
 PQ> last resort is SemPoint), I was sussing-out 'The Reader' when I
 PQ> realised... WTF!  What benefit will I get out of this!?!  Damn! 
 PQ> I've been stressing for someone else's f#cking benefit.  F#ck this
 PQ> sh#t!

hehe, been there :)

i have multimail here and actually have used it more than other BW/QWK offline
readers in recent years... it works as expected given the format of the mail at
that point ;)

 PQ> Have a squiz at the posts by Tom Walker & Ed Vance, both of whom
 PQ> use SLMR (in the Windows-type echoes).  With the kludge view option
 PQ> 'on' in _your_ reader, then tell me what's wrong with their posts &
 PQ> reply-threads?

ed is/was posting from a synchronet board... it is generating a MSGID control
line for the QWK imported messages just like most other bbs systems do...
maximus being one of recent conversation... it also generated a proper REPLY
control line for the message of tom's that ed was replying to... tom's post had
a proper MSGID control line in it so this appears to be working as designed but
that MSGID that synchronet generates is still wacky and doesn't provide what
the specs say it should provide... this is especially evident when trying to
reply via netmail to messages gated into fidonet that are from other
networks...

tom is posting from Doc's Place which runs Wildcat! PX something or other...
the offline packet software used there (can't tell if it is internal or an
addon) generates a MSGID control line but no REPLY control line for messages
that are replies to others with valid MSGID lines... again, this is the same
that other bbs systems do and have done for years... again, just like maximus
does as discussed in recent conversations...

bob klahn also posts via Doc's Place but he uses SilverExpress... that's
another package by the same folks now maintaining the wildcat stuff... "we"
went round and round with them in NET_DEV many years ago about numerous
standards and proposals that apparently were implemented "half way" because the
additional information simply was not available... they were trying to follow
FTS-0009 very strictly and were generating the MSGID in the offline mail
reader(s) they maintained... since there was no MSGID control line in messages
being replied to, they could not generate a REPLY control line... again, this
is because the QWK standard doesn't allow for these lines to be transferred in
such as way as to be unobtrusive... yes, some systems DO allow those lines to
be transferred but they are visible in all messages and they still cannot be
acted upon... acted upon as in the user manually creating a proper REPLY
control line to feed back to the system and have it properly converted to a
real control line... they just come back as text in the body of the message...

for systems that use only MSGID/REPLY linking, those threads get broken by
those packages which generate MSGID lines but cannot generate REPLY lines due
to the user using offline mail formats that do not handle FTN control lines...
there are, actually, some offline mail systems that do properly handle this but
it is all done on the bbs side and the user is completely unaware of this fact
just like they are quite unaware of the control lines...

NONE of this is any of the user's fault, though... they simply choose to use a
very popular and widespread method of participating in message networks... no
one wanted to use QWK on the RIME/PCRELAY network and then have to use a
completely different package on FTN networks... especially not after spending
good $$$ for the package... the real fault, if one were to really desire to
place blame for this, lies with the first developers to implement the QWK
standard in FTN software... the bigger problem was that a BBS might be in
RIME/PCRELAY and in fidonet so now how to separate the formats of the messages?
as far as the users were concerned, they were all messages in areas on the
bbs... and many bbs' don't have any way of determining which network format
those messages belong to... each of the tossers tosses only to the message
areas they know about using their own format...

so we have this hodge podge of mix'n'match and it works for the most part...
the ones that are really troublesome are those gating systems that do not
follow proper gating techniques and methods... like gating from one FTN network
to another without doing the double toss thing... or gating from a newsgroup
without proper conversion and maintaining of control lines for both sides of
the fence...

)\/(ark

 * Origin:  (1:3634/12)