Subj : soupgate and alternatives
To   : Avon
From : Oli
Date : Thu Jan 28 2021 14:42:04

Avon wrote (2021-01-28):

 A> On 27 Jan 2021 at 07:13p, Oli pondered and said...

 Ol>> Soupgate looked for 0000????.msg Soup files and couldn't open the
 Ol>> 0000????.MSG Soup files. This problem was introduced when I changed
 Ol>> the extension for Fidonet messages from ".MSG" to ".msg". It
 Ol>> exposed a

 A> Good catch... I also found that with an earlier version when running the
 A> export function Soupgate was looking for .CLO not .clo files...
 A> Perhaps this is the same issue?

Yes and no. It's defined in soupgate.c (and can be changed easily):

const char binkmailext[BINK_ALLTYPES][5]
   = {".out",".cut",".dut",".hut"};

const char binkflowext[BINK_ALLTYPES][5]
   = {".flo",".clo",".dlo",".hlo"};

const char packetext[5]
   = ".pkt";

const char messageext[5]
   = ".msg";

const char soupmsgext[5]
   = ".MSG";

The problem with "soupgate import" was that it used messageext, which is the extension for ArcMail (netmail) messages. The extension for the Soup files is defined by soupmsgext, but never was used on import. As long as both were ".MSG" in uppercase it didn't make a difference, but when I changed messageext from ".MSG" to ".msg" it didn't work as expected anymore.

Now it's fixed and they should work independent from each other.

 Ol>> Unfortunately the more I use soupgate the less I like it. It's
 Ol>> simple to use, but it's approach to FTN<->Internet message gating
 Ol>> is way to simplistic. No real charset conversions, no TZUTC
 Ol>> support, dumping the complete RFC822 header into kludge lines (even
 Ol>> multi-line fields), non-Gatebau compliant MSGID/Message-IDs. It's
 Ol>> the worst case scenario for dupes: changed datetime, changed text
 Ol>> body, changed MGSID, a bunch of weird kludges.

 A> Many kludges can be disabled by config file. I agree it's not perfect but
 A> the windows version has been working OK for several years for me without
 A> too many niggles on either side of the gate.

There are standards and best practices for a reason. It might work fine for you now, but in another scenario it might generate all kinds of weird side-effects and problems. Like the Mystic tosser with all it's non-standard behavior worked okay, until it didn't (AFAIK the various bugs have been fixed).

Soupgate is creating a real mess at re-importing and translating MSGID/REPLYs. One problem is that even for local use reply linking cannot work, when MSGID / Message-IDs aren't translated transparently back and forth.

Btw, I don't think binkp.net is meant to be used for mail/news gating and that fidonet.org would still be the better (only correct?) option for the Message-ID domain.

 Ol>> I wonder if it is best to look for better alternatives. I guess
 Ol>> even a rewrite from scratch would be not much more work then
 Ol>> extending and bugfixing Soupgate and Spoon.

 A> One reason I like the combo is that they are two stand alone exec files
 A> that I can install, config and run. It doesn't require a huge overhead to
 A> install something more complex..

That's what I liked with soupgate too ...

 A> But I agree fixing bugs and extending
 A> features would be great. Just wish I had the coding skills to do it :(

..... but then it's maybe more work (for us) to get it in a good state than learning to configure a complex monster like fidogate.

---
 * Origin: . (21:3/102)

.