You can't. Messages are written/edited before any other index sorting
is done. To support what you want, mhonarc would have to create sort
lists for all possible sort criteria (an expensive operation), and also
provide a bunch of resource variables to access them.
...
If the anchor names in the indices were built by rule from the message
ID, you don't have to have sorted the index lists to write the URLs
that index into their HTML representation. You do have to ensure that
every message has an ID, but I think that can be arranged.
I do not see how this solves the problem. Message Ids give absolutely
no indication of listing order, just possible location. It provides no
help in determine what is next, or previous, in date, subject, author,
or thread. When a "Next by Date" link is written, one still needs to
know what the actual next message by date is, message-ids do not help
in this. Note, we are not talking about indexes linking to messages,
we are talking about messages linking to other messages (the
navigational links provided at the bottom and top of each page). I
do agree that using message ids as indentifiers is better off, in
general, but they provide no assistance to this problem.
I believe the main problem is that mhonarc cannot store an arbitrary
number of index related information. If it could, all index pages can
be created first, and the listing orders stored so when the message
pages are written, they can access all the index sorts for next/prev
message links.
The other approach is that all links are dynamic, and the next/prev
message by whatever type is determined on the fly through a CGI
program, or similiar mechanism. However, this still requires some
sorted based lists to exist, and be maintained during updates, to
compute the next/prev message of a message. To be efficient, something
like a RDBMS, or similiar system, may be needed since a flat file
system approach would be too slow.
I like the dynamic approach better, because page maintenance becomes
much easier and the number of resource variables needed would be
reduced (and some not needed). However, that requires a whole new
implementation of mhonarc which would take some time. I've played
around with the idea of making mhonarc work off a RDBMS. With all the
RDBMS module extensions to Perl, I think it can be done. Here is where
message ids can be really useful when managing the messages.
--ewh
