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