> Wed, 19 Jun 1996 21:32:21 -0500, rsteiner@skypoint.com (Richard Steiner)
> wrote:
> >I may be viewing a message or two. Why should it matter? Methinx there
> >is tremendous inefficiency living in the Yarn folder code...
>
> It matters because if you read messages yarn marks them as read. THen when
> you exit it has to update the X-Status. To update the X-Status it seems to
> (for some reason) scan the entire folder-- hence the delay.
It seems to be using a very silly approach, or at least a semi-inefficient
one. A brute-force scan should never be used unless it's absolutely
necessary, just as a general rule.
I don't know the structure of the Yarn folder database, but I'd assume the
messages are stored in some sort of list format with each message having a
known offset of some type (some form of internal message number would do
if they're not stored in a formal array).
When a message is viewed or otherwise acted upon, Yarn should see if that
alters its status, and build a list of those messages which were acted
upon along with a list of the action(s) performed (assuming they result in
database changes in the first place).
That way, if you looked at ten messages, it would store the locations of
the messages you looked at, and when you exited the folder it would simply
perform ten updates to the known locations instead of resorting to some
type of brute-force scanning method to find any changes made.
It'd be easy to design some generalized algorithms if I knew the message
base format. Other features, like dupe checking/removal, are also easily
implemented given a message ID field and a creation timestamp, and I've
noticed that Yarn suffers from some problems in that area.
> Those are my non-scientific observations anyhow. And if you hit Insert to
> "unread" them before exiting yarn seems to have a flag somewhere that says
> there was a "change" made.. and so scans the whole folder on exiting anyhow.
> Wheee. A slight annoyance... but a situation I can live with.
It makes large folders unusable as quick reference sources. And the code
changes required should be fairly minor and easy to implement, assuming
there isn't some limitation in the message base format that prevents one
from building some kind of dynamic change status list against it...
--
-Rich Steiner >>>---> rsteiner@skypoint.com >>>---> Bloomington, MN
Written online (ugh!) using pine!
The Theorem Theorem: If If, Then Then.