TZUTC: 1000   
   MSGID: 17.fido-pascalle@3:633/410 2304e8a9   
   REPLY: 27.fido-pascalle@1:3634/12 23042ccf   
   PID: Synchronet 3.17c-Linux  Nov  3 2019 GCC 4.6.3   
   TID: SBBSecho 3.10-Linux r3.146 Nov  3 2019 GCC 4.6.3   
   CHRS: ASCII 1   
   -=> On 04-21-20 09:35, mark lewis wrote to Tony Langdon <=-   
      
    TL> Yeah I don't recall striking that in the TP days. Or is this   
    TL> a FP only bug?   
      
    ml> it is absolutely a borland bug... it affects all of their languages   
    ml> that used that form of delay calibration... nothing at all to do with   
      
   Ahh, OK.  I must have only had old slow machines LOL   
      
    ml> FPC... it reared its head when machines got fast enough for the   
    ml> calibration loop run to completion within the same second... so they   
    ml> increased the loop count and got bitten again when machines sped up   
    ml> again... i think they had one more round of it before someone finally   
    ml> smartened up and finally figured out another way to calibrate the delay   
    ml> routine...   
      
   Hmm, what version of TP did they finally fix that in?   
      
    TL> I'm not interested in web for most of my applications.   
      
    ml> the idea of my statement was to point to the existing working examples   
    ml> ;)   
      
   I think I have seen them, but there was a step or 3 of knowledge in between   
   that they dodn't cover.  I don't deal well with partial information unless I   
   can easily connect it to something I already know.   
      
    TL> TCP or UDP sessions are usually more useful to me, because I want   
    ml> processes to be able to talk across the network plainly. :)   
      
    ml> that can still be done even if using a so-called web-server/web-client   
    ml> setup ;)   
      
    ml> client sends a request.   
    ml> server sends some sort of response.   
    ml> client does its thing.   
      
   Yeah, true.  Most of my applications don't need the HTTP stuff, generally   
   fairly raw sessions.   
      
    ml> the request could be some format you come up with or maybe it would be   
    ml> something in JSON or using AJAX or something else... the response could   
    ml> be similar, as well... it just depends on what you want done...   
      
   Yep. :)   
      
    ml> i can envision serving JAM message bases directly to a client without   
    ml> any intervening format layering... maybe no binary by converting that   
    ml> to ASCII text for the transmittal... having a client/server message   
    ml> reader like that would be a first step toward doing a client/server BBS   
    ml> setup... sure, it would be a dedicated client for the users but then   
    ml> maybe the client would reside server side and convert to standard   
    ml> traditional terminal sequences so the entire client/server thing is   
    ml> completely hidden from the users...   
      
   Could be an interesting evolution, though I prefer to be relatively isolated   
   from the network for heavy duty messaging - maybe prefetching and cacheing   
   would achieve that, such a cache could be cleared when I log off or after an   
   expiry (probably 24 hours or less), so I'm not having to wait for   
   network/server responses everytime I go to the next message.     
      
   And once you go client/server, there's still the possibility of a web based   
   client for those who like that sort of thing.   
      
      
   ... It's funny because *I* said it!   
   === MultiMail/Win v0.51   
   --- SBBSecho 3.10-Linux   
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)   
   SEEN-BY: 1/123 90/1 120/340 601 226/16 30 227/114 229/101 426 452   
   SEEN-BY: 229/616 1014 240/5832 249/206 317 400 280/464 317/3 322/757   
   SEEN-BY: 342/200 633/0 267 280 281 384 410 412 416 712/848   
   PATH: 633/410 280 229/426