Fri 2003-02-14 11:11, mark lewis (3:633/267) wrote to andrew clarke:

 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...

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

 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...

Yep, but traversing the entire free list of a Squish base will still take
less time than having to traverse the message list of a JAM base, assuming
the length of the free list is shorter than the length of the message list
(a fair assumption to make).

-- mail{at}ozzmosis.com

--- Msged/BSD 6.1.1