-=> 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 calibration
ml> loop run to completion within the same second... so they increased the loop
ml> count and got bitten again when machines sped up again... i think they had
ml> one more round of it before someone finally smartened up and finally
ml> figured out another way to calibrate the delay 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)
|
