Tom posted <address@hidden>, excerpted
below, on Tue, 15 Jun 2004 22:10:30 -0400:
It looks to me that the Article structure is a big memory user. The thing
is, you rarely if ever display anything other than part 0 or 1, so to me
it makes sense to only keep the part 0/1 in memory, and retrieve from
DB/display the others on an as-needed basis
There are two ways to work with multi-parts. The one is to save the
binaries directly to disk as you download them. The other is to d/l them
to cache as one might d/l a single-part image or text post, to view (or in
this case save) later.
One small irritation with PAN is that for those (like myself) that prefer
the d/l to cache option, one has to keep switching between "view complete
multiparts as a single part" and "view individual parts of a multipart",
because if you select everything there when only the first part is shown
and tell it to d/l, it only d/ls the FIRST part.
The switching is one thing, but the IRRITATING part is when one forgets to
switch to multi-part-view layout, and therefore only gets the first part,
then when one goes to look thru them, only the FIRST part has been
downloaded and the OTHER parts may have already expired! THIS IS NOT GOOD!!
Anyway, how all this relates to the above quoted discussion is that if PAN
were modified to grab ALL parts when it is set to view only the first part
of a complete multi-part, instead of JUST the first part, viewing
individual parts would become even LESS common, as there'd be no reason to
do it just so one could select ALL the parts and have them d/led, instead
of just the FIRST part.
Therefore, if we are going to optimize memory use and not keep the data
for all parts of a multi-part in memory, we should also modify PAN to
fetch ALL parts when it fetches the first part, at least if view only the
first part is set. That way, there'd be even LESS reason to set it to
view all parts, so less reason to drag all that info back into memory for
display.
In fact, I'd suggest dropping the view as separate parts option
altogether, once PAN was set to retrieve all parts instead of just the
first. The view multi- feature would probably be little enough used, at
that point, that it would make sense to drop it, given the
(understandable) thing Charles has about little used feature bloat. That
would take care of the problem of having to keep that info in memory for
display purposes altogether, and PAN would only have to track the info
necessary to retrieve all parts, and then reassemble them when one DID go
to view/save them.