Proper threading? (technical spects)

[Steve Lamb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 11 Jun 1999 16:44:26 +0100, Dr. Martin R. Hadam wrote:

> 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.

    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 the
MSGID that it was, well, in reply to.  It then places the message directly
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-reply,
or, a thread.

    PMMail does not do this.

> 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.

    This is called an "index" and has very little to do with threading.

> There is also a file FOLDER.INI which seems to contain the folder
>structure and maybe the sort settings. 

    Please note the last two words.  "Sort settings."

>It's a single line and not relevant here. 

    However, you dismissed it too quickly.

>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.

    Nope.

> 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!!

    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 to 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.

> 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.

    PMMail doesn't do threading.  I've told you that already, though.
Folder.ini, sort preferences.  Again, a change in that file breaks
compatibility between the two versions.  I really should stop replying here
since, from this point on, you're proceeding on a faulty premise.

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

    Concurrant releases of PMMail(win) and PMMail/2 which is, as I stated,
slated for the next major version.

> 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.

    Except that it breaks behavior for people who want sorting by priority,
read/reply status.  You do *NOT* break current behavior to impliment new
behavior without good reason.  This is not good reason.

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

> 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. 

    And the configuration file which was my point from the beginning.  When
you catch up to the level that I'm on, and please do try to, maybe then
you'll
begin to have intelligent suggestions to make.  Until then, you're proposing
solutions which have already been thought of and disgarded for reasons which
have already been explained to you.

> 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.

    No.  It is dumb customers who do not understand the full consiquences of
what they are suggesting.

> 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).

    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.

> So why is it not changed? 

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

>>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.

    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 for the
"small shit" so they can work on the much larger and much needed things.

> 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.

    You've not been a part of *this* beta test program.  I cannot count how
many times that Bob impliments something the moment I am contrary to it.  Bob
and I toss emails back and forth from time to time.  I am quite a vocal
PMMail
user and beta tester.  I am not, however, by any means, Southsoft's
puppetmaster.

    LDAP got impliment despite my repeated objections to LDAP being put into
the product before IMAP.  I've been pushing for IMAP for, what, 3+ years now.
I've been pushing for IMAP since the days that the *ONLY* IMAP clients were
Pine from uwash itself and Simeon on Win/Mac.  PMMail is now one of the last
clients to implement IMAP.  I'm now trying to push a "proper" implementation
of IMAP instead of the crippled implementations that other clients have.  All
of that, however, is highly subjective to Southsoft's priorities which are,
by
not means, *my* priorities.

> 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"

    This is because you obviously don't understand how PMMail works
internally.  I've been using it since v1.5, been betaing since the same
timeframe, have been privy to how the internal logic works and I *still* get
it wrong from time to time.

> 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. 

    Provide examples and I bet I can explain why.

> 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.

    Read until you understand.  They do want to improve their product.  They
do not want to do it in a manner that breaks compatibility with the sister
product or in a manner that will delay future versions.  At some point, as my
boss put it, you have to start working "out of the box."  IE, accept what is
in the current implementation and work it out in the next.  This is something
that has been around for years, it is not easily fixed in their current
release schedule, it will be moot in the next major release as it will have
true threading.  

    LET IT GO.


- -- 
         Steve C. Lamb         | I'm your priest, I'm your shrink, I'm your
         ICQ: 5107343          | main connection to the switchboard of souls.
- -------------------------------+---------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc

iQA/AwUBN2E7Enpf7K2LbpnFEQIBlQCfeMbVzUQEx5CaYr0DZbBlIg2dZKkAoN0Z
zsCKZSMG8YHwXC8CKnzpoZw9
=inlH
-----END PGP SIGNATURE-----