Proper threading? (technical aspects)

[Dr. Martin R. Hadam]

On Fri, 11 Jun 1999 09:36:34 -0700, Steve Lamb wrote:

>    Mistake #1: PMMail does not do threading.
>> OK, how is threading done? 
>
>    Threading is done by matching the "In-Reply-To" line's MSGID with t=
he
>MSGID that it was, well, in reply to.  It then places the message direc=
tly
>below the message it was in reply to, usually indented.  This way, as a=

>conversation splits apart you can maintain a direct line of reply-to-re=
ply,
>or, a thread.
>    PMMail does not do this.

 You are correct noting that I've been using sloppy terminology and I
appreciate your well thought explanation for the dummies. However, from
the context of the ongoing discussion it was more than obvious that I
was referring to "Sort settings" throughout my email (with the one
exception of a quotation). Hence do a mental "search and replace" and
cut down half of your response as irrelevant.

>    Please note the last two words.  "Sort settings."
>>It's a single line and not relevant here. 
>    However, you dismissed it too quickly.

 Now - tell the uninformed what is in there other than pointers to the
"sort settings" of that particular folder?

 Since you prefer not read my earlier message let my try to explain to
you: The (on my system) 42 up to 55 Byte sized FOLDER.INI looks
(depending on sort settings) something like that:

    Inbox=CC1000=CC1=CC2;3;5;4;6;7;8;9;1;0=CC0=CC1=CC0=CC0=CC

 For you to notice I've inserted  >> << characters to point to the
"read status" pointer (which is a zero):

    Inbox=CC1000=CC1=CC2;3;5;4;6;7;8;9;1;>>0<<=CC0=CC1=CC0=CC0=CC

 Hence in the above example, it indicates that "read status" has the
lowest sort priority. It moves leftward if "read status" is given a
higher priority. This zero character (like all others) is independent
of operating system and of any of the changes I had suggested.

 Hence whenever a system implementing the
           "read status" sort algorithm change
 (please read every single word carefully and try to comprehend what it
means) that I have suggested in my earlier email encounters a
folder.ini file (as in the example above), it will sort "read status"
with the lowest priority, yet only take "unread" messages into account.
If you set the sort settings such that read status is on top, all
unread will go to the top of the list and the remainder will be sorted
only to the second and following sort criteria (e.g. subject).

 If a pmmail version that still uses the current algorithm uses this
FOLDER.INI, it will do exactly the same, EXCEPT for the behavior of the
READ STATUS sort. This time, not only unread, but also sent,
replied-to, draft, priority etc is used for sorting.

 SAME THING if your reindex in both situations. 

 Hence there is absolutely NO INFLUENCE of the FOLDER.INI file under
the provisions described for implementing such a modified "read status"
sort algorithm despite your claims to the contrary. Please try to think
and understand about it to the extent of actually looking at the files
before writing more emails.

>Give the man a cookie!  Wait, nevermind, he got it wrong.
>You're right, it is happening during the display time but you missed
>something.  It would require a change in the sort preferences which, as=
 you
>correctly identified, would be stored in the folder.ini. PMMail needs t=
o be
>told that people want to sort a certain way which means a change in
>folder.ini which will break one version or the other.

 Hope you're not on a diet and eat those cookies yourself.

 If you had read what I've been trying to explain and not just written
inflated responses, you'd have realized by now that I did not suggest
to change sort preferences - I suggested to change the sort algorithm
for the "read status" sort preference. To the extent of repeating
myself - "read status" currently sorts for integers from 0 to 11 (or
more? doesn't matter here). My proposal was to change that sort
algorithm to a kind of "binary" sort of "0" vs all the rest.

 I'd maintain that this is a very easy thing to do (if you have the
source code <bg>). However there was one response on the list (but not
from you) that has to be taken seriously because it was right to the
point, such that this proposed change was not trivial. I do not agree,
but I accept that this is a valid argument. I'd like to reiterate here
that this is only about sorting 
   0,1,2,3,4,11 (and a few other integers) in numerical order
versus
   0 and (1,2,3,4,11, etc)
(it's not "real threading" as the other respondent has been talking
about)

>Except that it breaks behavior for people who want sorting by priority,=

>read/reply status.  You do *NOT* break current behavior to impliment ne=
w
>behavior without good reason.  This is not good reason.

 This is a valid argument - yet I'm not sure if there is any measurable
quantity of people doing that. My argument is based on the fact that
"unread" and "high priority" are sorting to the extremes of the sort
spectrum (0 vs 11) which is something that no-one with a healthy mind
might anticipate. The other quantity - those who want to have unread on
top and all the rest sorted in - is pretty significant, however. 

 Hence I'd like to ask if there is a single member on this list who
does USE the read status setting to find priority emails or his own
sent mail or the mail that he replied to? I'd appreciate if this
individual stood up and voiced an informed opinion.

>That means you need to add in a configuration option, changing the
>configuration files, breaking compatibility.

 Try to learn a second sentence - there is NO break in compatibility,
there is NO configuration needed for what I have proposed. period.

>Except you would be completely destroying the current sorting behavior,=

>not implimenting threading, and doing so for no good reason other than =
a few
>people who are complaining which would at least be matched or exceeded =
by >the number of people who would complain when you destroy it.

 I've never been talking about "real" threading (see my above
provisions for sloppy terminology) - YOU want threading.  And I'm not
proposing to  completely destroy current sorting behavior - my
suggestion only does what "READ STATUS" suggests by its utter
characters: "read" vs "unread". No more. (you'd have a hard time
reasoning that "priority" has something to do with "read status" to a
novice user). 

 It admittedly breaks sorting for priority etc, but honestly - I
couldn't care less. I'd estimate that the count of users applauding my
proposed changes outnumbers those disapproving it by a factor of more
than 10 (ten).

>Read above, understand.  If you fail to understand, read again. Repeat
>until understanding comes to you in a zen-like moment of epipheny.

 While I've carefully read your email even to the point of
understanding (not approving) your point - it occurs to me that you
have up to now not grasped the underlying assumptions of my
suggestions. You keep reiterating a compatibility problem that just
does not exist.

>No.  I think I've stated my case quite clearly by now.  I am a big
>proponent of reducing the amount of work that Bob and Ike need to do fo=
r the
>"small shit" so they can work on the much larger and much needed things=