Proper threading? (technical aspects)

Dr. Martin R. Hadam Dr. Martin R. Hadam" <Hadam.Martin@MH-Hannover.de
Fri, 11 Jun 1999 23:34:08 +0100


On Fri, 11 Jun 1999 12:48:25 -0700, Steve Lamb wrote:

 I'll try to make it short: 

>100% *WRONG*.
>IF YOU CHANGE THE ALGORITHM YOU NEED TO MAKE IT AN OPTION ELSE PEOPLE WILL
>COMPLAIN.  BY MAKING IT AN OPTION, WHICH IS A REQUIREMENT, YOU MUST ALSO
>CHANGE THE CONFIGURATION FILE.  THAT MEANS A CHANGE TO FOLDER.INI WHICH, IN
>TURN, BREAKS COMPATIBILITY.  

 Despite the capitalization (which makes it difficult to read) you keep
introducing features which I never asked for. 

>    A leads to B leads to C.  Please attempt to follow along!

 (I am... ) which most naturally leads to *your* conclusions. 

 My issue was only to change the current sort algorithm to something
better. This may leave some users behind yet is compatible across the
board and a significant improvement (imo). You may dispute the
improvement, but you'll have a hard time demonstrating that it will
break compatibility with the Windows (or older OS/2) version(s). 

>You are aware that there are 3 unread status, right?  
>High Unread
>Normal Unread
>Low Unread
>You are aware that until PMMail98 it sorted it as:
>Normal Unread
>High Unread
>Low Unread
>    ...Right?

 Wow - I am impressed. You do know a *lot* about PMAIL's the
internals!!! with the "binary" sort that I've proposed, just treat
">High Unread >Normal Unread >Low Unread" like the "0" (I'm sure you
will come up with some more insider knowledge about those numbers). I'm
actually too lazy to care about. And it does not matter what the values
are.

 With these added "hurdles" the sort logics are now 

   if msg_priority code = ("0" or "  "High Unread" or "Normal Unread"
or "Low Unread") then msg_priority code=0 
   else msg_priority code=1
   (then submit to *standard* sorting)
 
 In case you have some more food for "deep thinking" please care to
fill it in the code fragment above at the appropriate places yourself,
if you find it challenging.

 With those provisions included, my proposal still works.

 
 There is even another, completely compatibilty-friendly way of doing
it (sorry that I did not think of it before): There's a switch in the
settings notebook "use old style read status sorting" which allows for
changing between two sort modes. Yet both of them being much less than
optimal. Just USE this checkbox and have my suggestion on the way to
sort "unread" only being activated by this switch.

 Of course you may immediately note that those who used this switch
before will now in turn claim broken compatibility. Well, I don't care
(again) because if you need sorting for priority - you uncheck it - if
you need sorting for unread only - check this (that's what old users
for pmmail/2 wanted in first place).

 I'm sure it won't create any problems with the Windows version
(because the current one doesn't either), thus making all your prior
arguments to collapse. Yet since it's me to state this here I'm
expecting vigorous disapproval from you.


 To me this is the best of both worlds at an acceptable price (i.e.
effort to make it happen) and without a major wait for a major release.
Given the (slow) speed of development with the current beta, adding
this feature still makes sense, imo. As it's using a known and proven
way of doing things (i.e. using "use old style read status sorting") it
is not supposed to break compatibility in any significant way.

 This is a technically sound proposal, which could be realized in no
time by a proficient programmer, if really wanted.

 I'd say this is something that pmmail users should ask for - now.

 Martin


 Martin R. Hadam
 Kinderklinik - Medizinische Hochschule
 D-30623 Hannover
 Germany
 Email: Hadam.Martin@MH-Hannover.de