ac>> The main benefit of running Squish bases was because they
 ac>> could auto-pack themselves.

ml>> the bases, themselves, can't but the software (squish) that
ml>> manipulates them can...

 ac> The format specifically allows for it and the MSGAPI (which
 ac> most programs use) provides the support for it.

that's (kinda) what i said... the software (the API) provides support for
it... the data structures can't do it directly themselves...

 ac>> I don't think JAM was designed to do this.

ml>> sure it can... its just a matter of coding it in the utils...

 ac> Except it's not really practical.  In a JAM base, if the
 ac> spaced used by a deleted message were to be reused
 ac> (autopacking), the program would need to run through every
 ac> message header checking if it was marked as deleted, and then
 ac> check whether the space used by the deleted message was big
 ac> enough for the new message to fit, and if not, keep going.  If
 ac> it turned out there were no deleted messages, and you had a
 ac> message base with 20,000 messages in it, it could take a while
 ac> to save just a single message.  Which would be a big
 ac> performance hit for a mail tosser importing lots of messages,
 ac> which is ideally when you really want autopacking to work.

why do it that way, anyway? just append the message(s) and pack when
done... or pack first then append... why mix today's messages in the base
with those from last week? that causes a lot of seeking back and forth and
back and forth...

 ac> On the other hand Squish maintains its own "free frame list"
 ac> (a linked-list of messages that have been deleted) which is
 ac> independent to the "stored list" (a linked-list of stored
 ac> messages).  A program need only traverse the free frame list
 ac> to look for reusable frames, assuming it honours autopacking.

and you still have the same situation with is there enough space to put
this message text in that deleted message's spot...

 ac>> You could convert all of these to Squish format using FmaCopy.

ml>> and loose access to them from my BBS software and my (current
ml>> preferred) mail reader? no thanks...

 ac> I wasn't suggesting you should.

> if i were to convert them, it'd do me no good other than
to give me access to them in TimED/L... then i still have to maintain
them...

)\/(ark