Mac Forum / Applications / Eudora / November 2005

In article
<1h6i65z.1mazwt514assxmN%robk200401_AT_badeend_DOT_nl@nowhere.nowhere>,

Yes, I believe it is. Redefining the frormat of one data field doesn't
solve the underlying problem. You've asked about this before and seen
the answer before, but maybe you didn't understand it.

Eudora mailboxes have indexes that include 220 bytes per message in a
single MacOS resource of type TOCF  in the resource fork of the mailbox
file.  Each message MAY have an error message string associated with it
and stored as a resource in a 264-byte structure. A user may choose to
have Eudora keep the last known valid TOCF as a second resource. No
MacOS resource or resource fork can ever be over 16MB. Do the math.

If you knew anything at all about programming for MacOS, you'd
understand why this is not about redefining the size of one variable, it
is about a complete rebuild of the mailbox format from the ground up.
The Resource Manager was a great feature of classical MacOS, and I wish
Apple had chosen to work out a way to bring it into the modern age, but
they chose not to. Programs that use the Resource Manager are limited by
its early 80's design and its lack of any updates in about 15 years.

In article
<1h6nkjg.1d7ew3q16mkcbsN%robk200401_AT_badeend_DOT_nl@nowhere.nowhere>,

I am not sure, but I doubt that would solve the problem. I believe
Eudora uses the same local data structure using the MacOS Resource
Manager to index IMAP mailboxes as it uses for local mailboxes.

They COULD, but what's important to understand is that any significant
change they make will require a major rewrite.

You and I had this conversation over a year ago, and reality has not
changed. The format of the resource fork of a Eudora mailbox makes it
possible for the indexing and metadata for 32K messages to just fit in
under the limits of a MacOS resource fork. The 32K limit is a natural
one -- the maximum value for a signed 16-bit integer -- and the next
natural one up would be 64k -- maximum unsigned 16-bit integer. The
problem with that one would be that it would effectively eliminate
everything else that Eudora puts in the mailbox resource fork other than
the single TOCF resource. Messages would lose the ability to retain
associated error messages and you could not have a resource-based
backup. Beyond that, any higher limit would mean putting the metadata
for mailboxes in files distinct from the mailboxes themselves, or else
abandoning the format used for actual message data, which is a slight
variation on the traditional "mbox" format.

This doesn't mean it can't be done, and I hope Qualcomm is doing it, but
it does mean that making a change lifting the limit will require a lot
of work, not just a matter of a recompile or minor tweaking. A change
will mean a fundamentally incompatible change in the overall mailbox
format. I think this needs to happen because the mbox+resource model
does not fit with where every other high-performance mail client is
going or where MacOS is going with system-level search. I don't expewct
that many people using Eudora really care about the 32K limit per se
because of the many purely functional problems you run into well before
you hit that many messages.