Subj : Re: Still here
To   : mark lewis
From : Tony Langdon
Date : Wed Apr 22 2020 11:32 am

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