All,

I'm running Synchronet now with its proprietary message base. I'm playing with Mystic and debating whether JAM or SQUISH (and their respective tossers) are a better choice. Does anyone have experience with both you'd like to share?

I used Squish for years with Maximus, and miss the variety of third party apps for stats, logging, netmail routing, etc. I know both have third-party apps, any experience with those would be helpful, too.
--- SBBSecho 2.27-Win32
* Origin: http://realitycheckbbs.org | tomorrow's retro tech (1:218/700)

I'm running Synchronet now with its proprietary message base. I'm
playing with Mystic and debating whether JAM or SQUISH (and their respective tossers) are a better choice. Does anyone have experience
with both you'd like to share?

If you are going to use Mystic then you should use JAM because the author may be removing Squish in the next version. No one really uses Squish with Mystic.

I used Squish for years with Maximus, and miss the variety of third
party apps for stats, logging, netmail routing, etc. I know both have third-party apps, any experience with those would be helpful, too.

I think JAM is considered to have better 3rd party support these days. In the case of Mystic, you don't need any 3rd party software as it has a tosser and mailer built it, but you can still use 3rd party stuff if you want to.

--- Mystic BBS v1.12 A1 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

Re: JAM versus Squish?
By: Kurt Weiske to All on Fri Nov 13 2015 04:35 pm

All,

I'm running Synchronet now with its proprietary message base. I'm playing with Mystic and debating whether JAM or SQUISH (and their respective tossers) are a better choice. Does anyone have experience with both you'd like to share?

The Synchronet Message Base (SMB) is no more proprietary than JAM or Squish.

I used Squish for years with Maximus, and miss the variety of third party apps for stats, logging, netmail routing, etc. I know both have third-party apps, any experience with those would be helpful, too.

JAM and Squish are older formats than SMB, so they benefitted more from the BBS "boom times" where there were more developers involved creating more cool stuff. Of course, being older, they (JAM and Squish message base formats) have problems that SMB specifically avoided. So it's to get the increased options awarded to you by using an older file format while also avoiding the shortcomings of those file formats. C'est la vie and I wish you luck.

digital man

Synchronet "Real Fact" #10:
DOVE-Net was originally an exclusive ("elite") WWIVnet network in O.C., Calif. Norco, CA WX: 68.3°F, 29.0% humidity, 2 mph SE wind, 0.00 inches rain/24hrs

Hello Kurt!

13 Nov 15 16:35, you wrote to all:

I'm running Synchronet now with its proprietary message base. I'm
playing with Mystic and debating whether JAM or SQUISH (and their respective tossers) are a better choice. Does anyone have experience
with both you'd like to share?

Squish is more resistant to breaking than JAM, in my experience. MBSE uses JAM but takes care of itself mostly. These days, the difference is more six in one hand, half-dozen the others.

Later,
Sean

--- GoldED+/LNX 1.1.5-b20150715
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Re: JAM versus Squish?
By: Rob Swindell to Kurt Weiske on Fri Nov 13 2015 06:41 pm

The Synchronet Message Base (SMB) is no more proprietary than JAM or Squish.

Sorry, I misspoke - not sure what word I meant, but I think you got my drift; there aren't as many third party utilities out there for SMB compared to JAM. I never used JAM back "in the day", not sure of the benefits/disadvantages of each.
--- SBBSecho 2.27-Win32
* Origin: http://realitycheckbbs.org | tomorrow's retro tech (1:218/700)

On 11/13/15, Kurt Weiske said the following...

I'm running Synchronet now with its proprietary message base. I'm
playing with Mystic and debating whether JAM or SQUISH (and their respective tossers) are a better choice. Does anyone have experience
with both you'd like to share?

In my early days as a Sysop I used squish with maximus as well.. :)

Since then I have always prefered squish over jam probably for no reason
other than it worked for me. I liked the way in squish msg bases you didn't need to pack your msg base if you deleted a message. The freed space would be used by the next incoming msg that would fit in that space or simply be freed when you packed your msg bases. I liked the way that worked in netmail bases were msgs can come and go quickly.

I asked this question in the husky (a tosser for squish and jam) area
recently to see if someone had an answewr for me. I got one reply that said that the squish base can only link 12 (i think it was 12) reply links to the original message). It's a limit of the quish message base format that I never new of and has never been a problem. He told me he had one base with over 100,000 msgs!

On the jam side I have also used jam extesively with RA and MBSE (and now Mystic) and have never had a problem with it.

I also like to look at other bbs software from time to time and Synchronet is on my hit list. I rather like it's format to, very configurable I have never had a problem with it either.

Ttyl :-),
Al

--- Mystic BBS v1.11 (Linux)
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Re: JAM versus Squish?
By: Kurt Weiske to Rob Swindell on Sat Nov 14 2015 09:25 am

Re: JAM versus Squish?
By: Rob Swindell to Kurt Weiske on Fri Nov 13 2015 06:41 pm

The Synchronet Message Base (SMB) is no more proprietary than JAM or Squish.

Sorry, I misspoke - not sure what word I meant, but I think you got my drift; there aren't as many third party utilities out there for SMB compared to JAM. I never used JAM back "in the day", not sure of the benefits/disadvantages of each.

No problem. I considered both JAM and Squish message base formats for Synchronet (version 2), but ultimately decided that something better was needed. For most sysops, any of the mentioned formats should be fine.

digital man

Synchronet "Real Fact" #84:
The ZMODEM file transfer protocol is limited to files of 4 gigabytes or smaller.
Norco, CA WX: 64.6°F, 28.0% humidity, 3 mph SSE wind, 0.00 inches rain/24hrs

Alan Ianson wrote to Kurt Weiske <=-

I asked this question in the husky (a tosser for squish and jam) area recently to see if someone had an answewr for me. I got one reply that said that the squish base can only link 12 (i think it was 12) reply
links to the original message). It's a limit of the quish message base format that I never new of and has never been a problem. He told me he
had one base with over 100,000 msgs!

I've had over 20 links to the same message when I was running Max/2. I
think that may have been a limitation of DOS or something...

--Sean


--- MultiMail/Linux
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

On 11/14/15, Sean Dennis said the following...

I've had over 20 links to the same message when I was running Max/2. I think that may have been a limitation of DOS or something...

That could very well be. I rarely if ever pay attention to the reply links so it's not something that I would notice.

Ttyl :-),
Al

--- Mystic BBS v1.11 (Linux)
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

14 Nov 15 21:02, you wrote to Alan Ianson:

I asked this question in the husky (a tosser for squish and jam) area
recently to see if someone had an answewr for me. I got one reply
that said that the squish base can only link 12 (i think it was 12)
reply links to the original message). It's a limit of the quish
message base format that I never new of and has never been a problem.
He told me he had one base with over 100,000 msgs!

I've had over 20 links to the same message when I was running Max/2.
I think that may have been a limitation of DOS or something...

looking at the squish message base specs, the number of linked replies is evidently a limitation of the software design... it appears to be easy enough to change but perhaps all software being used on one system would need to be changed at the same time? since it is an array field, everything must be able to count the same range ;)


from the Squish Developer's Kit v2... starting at line 423...


replies UMSGID[9] 178 If any replies for this message are
present, this array lists the
UMSGIDs of up to nine reply
messages.



and this from the maximus msgapi.h...


[...]
/* Number of reply fields in XMSG.replies */

#define MAX_REPLY 9

[...]
/* The eXtended message structure. Translation between this structure, and *
* the structure used by the individual message base formats, is done *
* on-the-fly by the API routines. */

struct _xmsg
{
dword attr;

byte from[XMSG_FROM_SIZE];
byte to[XMSG_TO_SIZE];
byte subj[XMSG_SUBJ_SIZE];

NETADDR orig; /* Origination and destination addresses */
NETADDR dest;

union _stampu date_written; /* When user wrote the msg (UTC) */
union _stampu date_arrived; /* When msg arrived on-line (UTC) */
sword utc_ofs; /* Offset from UTC of message writer, in *
* minutes. */

UMSGID replyto; /* This is a reply to message #x */

UMSGID replies[MAX_REPLY]; /* Replies to this message

*/
dword umsgid; /* UMSGID of this message, if (attr&MSGUID) */
/* This field is only stored on disk -- it *
* is not read into memory. */

byte __ftsc_date[20];/* Obsolete date information. If it weren't for the *
* fact that FTSC standards say that one cannot *
* modify an in-transit message, I'd be VERY *
* tempted to axe this field entirely, and recreate *
* an FTSC-compatible date field using *
* the information in 'date_written' upon *
* export. Nobody should use this field, except *
* possibly for tossers and scanners. All others *
* should use one of the two binary datestamps, *
* above. */ };



and this from mark may's MKSRCMSG PASCAL library...

[...]
Const
SqHdrId = $AFAE4453;
SqLinkNext = 0;
SqLinkPrev = 1;
SqNullFrame = 0;
SqFrameMsg = 0;
SqFrameFree = 1;
SqFrameRLE = 2;
SqFrameLZW = 3;
SqFromSize = 36;
SqToSize = 36;
SqSubjSize = 72;
SqMaxReply = 10;

[...]

Type SqMsgHdrType = Record
Attr: LongInt; {Msg attribute}
MsgFrom: String[SqFromSize - 1]; {Nul Term from name}
MsgTo: String[SqToSize - 1]; {Nul term to name}
Subj: String[SqSubjSize - 1]; {Nul term subject}
Orig: AddrType; {Origin address}
Dest: AddrType; {Destination address}
DateWritten: LongInt; {Date/Time msg written}
DateArrived: LongInt; {Date/Time msg arrived here}
UtcOffset: Word; {Minutes offset from UTC}
ReplyTo: LongInt; {Original msg}

Replies: Array[1..SqMaxReply] of LongInt; {Replies}

AzDate: String[19]; {AsciiZ "Fido" style date}
End;



)\/(ark

... BBS busy. (C)all back later (T)hrow tantrum?
---
* Origin: (1:3634/12.73)

James,

If you are going to use Mystic then you should use JAM because the author ma

I thought JAM was something you put on biscuits. <G>

Daryl

---
* OLX 1.53 * Computers are not intelligent. They only think they are.
* PDQWK 2.53 #5


--- GTMail 1.26
* Origin: The Thunderbolt BBS - wx1der.dyndns.org - GT Power 20 (1:19/33.0)

Re: JAM versus Squish?
By: Daryl Stout to James Coyle on Sat Nov 14 2015 13:00:00

James,

If you are going to use Mystic then you should use JAM because the
author ma

I thought JAM was something you put on biscuits. <G>

Daryl

Well, These days , they Extended the JAM and remake Electronicly
Now, it's good to use it on computer


TT

... The greatest problem about old age is the fear that it may go on too long. --- SBBSecho 2.27-Win32
* Origin: SpaceSST BBS (1:249/206)