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