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> Even on a fast system, do you know how long it takes to pack a
 ac> JAM base of 20,000 messages?  Now do this each time you want
 ac> to save a message to the base.  This is what you're
 ac> suggesting.

no, it is not what i'm suggesting... reread my paragraph... "pack
first then append new messages"... yes, i know how long it takes to
pack JAM bases... i've several here that are in the 20000 message range...

 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> Yep, but traversing the entire free list of a Squish base will
 ac> still take less time than having to traverse the message list
 ac> of a JAM base, assuming the length of the free list is shorter
 ac> than the length of the message list (a fair assumption to
 ac> make).

on a fast machine, what does it matter, really?? what's wrong with normal
procedures of toss and scan mail during the day and then pack and purge
during midnight maint when no one is ont the system anyway? my system has
been running this way for years and never fallen apart yet... yes, my
system does maint with users logged in, too... its easy enough with a
properly designed setup...

)\/(ark