Proper threading? (technical spects)

[Dr. Martin R. Hadam]

On Tue, 08 Jun 1999 10:44:53 -0700, Steve Lamb wrote:

>No.  I'm one of the 99 who understands what is going on and am making d=
o
>with the workaround until Southsoft can fix the problem in a manner so =
that
>they don't lose customers.  I'm sorry you're the 100th asshole who can'=
t see
>that.  My mistake for thinking you were a rational person.

 I didn't respond yet because I was (a) *very* busy otherwise and (b)
interested in a solution. I usually take your wording as an
acknowledgement and hence won't respond to that.

 I'm trying here to go into the basics of threading as done by PMMAIL
and I will demonstrate to you and everyone very easily that some of the
claims made here during the earlier discussion are simply not correct.

 I'm not necessarily implying that some of the statements you made
have originated from you personally; I do recognize that you may just
pass on (incorrect) information from SouthSoft. Hence you may be
tempted not to expand your vocabulary.

 OK, how is threading done? 

 All messages in a folder are "referenced" with a separate line in a
file FOLDER.BAG which is appended at the bottom with each new message
in that folder.

 There is also a file FOLDER.INI which seems to contain the folder
structure and maybe the sort settings. It's a single line and not
relevant here. There is also a FOLDER.EXP which a zero-byte file and
only seen in some folders - it may only be the large ones and hence
*could* be a dummy to hold temporary data. Again, it will  not
contribute to the discussion here. Other than that, there are no hidden
files in the folders - so it's only *.msg and the above files. There's
also no file in the pmmail root directory that contains any threading
data; the only file that is updated in this location is pmmail.ini
which is far too small to contain anything related to threads. Same
applies to the \tools directory. 

 From the above it is obvious that anything related to threading of a
folder must be contained within FOLDER.BAG on disk or in temporary
memory of the software. "Tertium non datur" is what our ancestors would
have stated at this point.

 It also makes sense, because both OS/2 and Windows can read FOLDER.BAG
to assure "compatibility"; yet the actual index in memory is "volatile"
and "proprietary" to each operating system.

 So let's look into FOLDER.BAG:
=3D=3D=3D=3D=3D
3=CC0=CC1999-06-08=CC13:38:10=CCRe: Proper
threading?=CCpmmail-l@musthave.com=CCpmmail-l@musthave.com=CCHadam.Marti=
n@MH-H
annover.de=CCDr. Martin R. Hadam=CC2K=CCFD0RNM0.MSG=CC
=3D=3D=3D=3D=3D
This a sample line from one of my folders referencing to a "sent" file
by myself. If you look through this line, all entries are probably
obvious except for the integer at the beginning of the line. 

 I thus analyzed a number of folders and always found the same
invariable base structure, with the following variations in the first
position:

 0 =3D unread file
 1 =3D standard file with no "read status attribute"
 2 =3D replied-to file
 3 =3D sent file
 4 =3D draft
 11 =3D priority high

 I did not care to check for any others, like "priority low". Please
note also that FOLDER.BAG is *not* physically *sorted* according to the
above parameters. Rather its order is strictly determined by the
sequence of the incoming messages (new ones are appended).

 So - how the heck is the index generated? and where is it stored?
(sorry if all this is painfully slow <g>): you guessed it - it's all
happening at run time in memory!!

>And while it is all fine and good that you want it broken, I'm
>sure the people who use PMMail/2 and PMMail98 on the same
>machine would have a different opinion.  

 Which means that any claims that you could not change threading in
OS/2 without affecting PMMail98 are false if not blatant lies (please
read my introduction in case your blood pressure raises here). Unless
you or SouthSoft can point me to the file (including file name and
standard path) where PMMAIL *threading* information is stored on disk,
my conclusion remains valid.

 How could one use that information to remedy the situation - provided
one really *wants* to do so?

 Well, if you look at the sort order created by "read status" - it
displays the files exactly in the sequence defined by the integers
above: from 0 to 11 (or whatever). Again, keep in mind that this is all
happening in memory (on OS/2, Windows, you name it). 

 What happened if you made this a binary sort - of the kind: sort only
"zeroes" and keep the remainder indifferent? Well - it would just
result in the solution that many people have asked for and which laid
the ground for this extended thread.

 I'm almost certain that someone at SouthSoft would stand up now and
claim that this would "break their object structure" (one of their
favorite excuses). Actually, even "objects" are not made from whipped
cream but finally boil down to lines of ascii characters in program
code. And in the "sort object" (or whatever its name is) all that is
required was one additional line of code; something like
   if integer_coding_for_status>1 then integer_coding_for_status=3D1
to be inserted before the call to the actual sort routine or in the
routine itself.

 Please note that this is a proof of concept - not an actual code
sample. Yet it *could* be done with that conceptual single line. But
even in a worst case scenario (for performance reasons), no need for
more than a few (trivial) lines of code.

 Let me point you again to the fact, that no file on disk (other than
pmmail.exe) needs to be changed for this change to happen and that the
resulting software resp email data remain fully compatible with other
operating systems. Again, simply because the actual index is built in
memory. This means that even if you changed only the OS/2 version, you
could still see the other (original) sort type with the windows
version. No change whatsoever.

On Tue, 08 Jun 1999 10:51:01 -0700, Steve Lamb wrote:
>However, as I have stated, REPEATEDLY, since they have the two
>versions of PMMail out on different release schedules and they don't
>want to break compatibility between the two, they are hold off on a
>LOT of fixes and changes so they can do a concurrant release with
>the next major release.

 Let me come back to your statements from your parallel email on the
same day. Based on the above, it is obvious that your (SouthSoft's)
statements are not tenable. If they maintain that explanation, it's
just a lie in a high-tech disguise such that those dumb customers won't
notice.

 In fact, changing the threading problem to the better as discussed
here would require much less time than it took me to write this email.
And the change could even be incorporated in the Windows version (if
one wanted to in the same time).

 So why is it not changed? 
 
>Actually, no.  I'd much prefer referenced base threading if I could.

 I think you provide a clue here. You are not interested in that change
yourself and as one of the most verbal beta testers you keep talking
about sour grapes - yet don't look at the peaches within reach of you.

 I've been taking part in sufficient beta programs to know that if some
"key" personalities don't want something to happen - it just won't
happen. And you're not pushing that issue - most obviously.

 I must admit that I have no trust in any of SouthSoft's statements
because they usually go the way - as we say here, if you ask for
something unavailable in a shop: "oh, it doesn't exist" .....  "oh, we
don't have it on stock" ..... "oh, come back next week"

 For example, I've been told repeatedly on earlier requests of mine at
Southsoft that some feature would not be compatible with PMMAIL's
current object structure - yet suffice to say that I know that exactly
this feature works in PMMAIL! Sorry, but I have not trust any more in
the accuracy of their statements. 

 If SouthSoft wanted to exercise a few minutes to improve their
product, and the betatesters also said they wanted it - this feature
will be in the next *minor* release.  And if it is claimed that this
proposed change breaks compatibility to other PMMAIL versions or data,
this is correct to the extent that removing Internet Explorer breaks
Windows98.

 With best regards

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