[Oberon] Multiple incompatibilities with ISPs

[eas-lab at absamail.co.za]

As previously noted:
  there are very few System 3 internet users - posting by S3 is 'traceable';
  increasingly, internet usage is at the heart of computing.


I believe that those of us who still use S3 for internet access, just had
enough influence or made enough noise to get the 'code adjusted to
work with our setup'.  This empirical approach is partly due to the fact 
that the system (of S3 machine and the world of ISPs) can't be 'covered'.
The developer needs to make a reconnection to his ISP to get a single test
run. And his ISP is only a specific (single case) test case.

Knowing how S3 interacts with the world-population of ISPs,
moves one out of 'hard science' and the use of statistical/empirical
observations (over hard logic) is appropriate.

Here are my observations: ---------------------
 *  when I started V2.3.2 stand alone (? 5..9 years ago) Mail.Panel 
     would not 'connect'.  After some investigation, I suspected some 
     'timing' reason (the complication is the need for 'compatibility'
     of the user's setup and the ISP). 
*  TextMail.<commands> connected OK.
*  V2.3.6 DOS based still failed to connect via Mail.Panel.
*  2001 beta version now finally connected via Mail.Panel.

At one stage my previous modem (still used occasionally for faxing)
would not seize the line, yet linux and DOS dialers would !
Suspicions of changing line impedance or 'central supplied voltage'
were not confirmed.
Two points:
1.  it's very difficult to develop and test when you depend on the outside
        world - the telco and ISP.
2.  with a small community like ours, amortising the development and
      maintnance 'cost' is a problem, and after any problems, users just 
     'drop out'. But they don't say anything.  
      That's why you all just use microsoft ?  But don't admit it.

When my ISP changed so that the "@" char was part of my login
userID and/or password, the existing (false) assumption that
"@" was not permitted here made the system fail.
I patched my code.  Other potential users would just revert to MSoft.

S3's  pop3 implementation not to RFC: ---------------------

For years my pop3 'worked OK'.
Then with a new ISP,  TextMail.Directory showed =< 3 entries.
This because the ISP's echo at this stage of the dialog was 
"... POP3 $Revis", and the code searches for the first numeric
string to show the directory entry-count.

Again, apparently previous versions of mail servers 'tended' to show
the entry-count;  it seems that the S3 code was built empirically, rather
than theoretically from the RFC.   Again I patched my code to use
the RFC specified 'call' to get the 'number of entries'.

Looking back to an old pop3 RFC to justify the 'design' -  ie. perhaps
previously the 'number of entries' was automatically given without
the "STAT" command. The older RFC still implied that the S3 code
would not guarantee the directory entry-count.

My conclusion is that once the break down rate (due to non-RFC
compliances working their way through) exceeds the maintenance 
rate of the 'product', death of ETH oberon as a work-horse is inevitable.

The last thing we need is a few isolated users patching their code 
individually.  Where is the central control !

-- Chris Glur.