Hey folks, Ive been around the circuit promoting an idea Ive been working on, to allow us with wifi enabled machines to have a web-like experience on these retro machines. They will never be able to keep up with the ever demanding requirements of modern
day web browsing, so I believe that we can come together with other retro enthusiasts and develop a low footprint web like protocol of our own. Hence, my project is called RHML (retro hypertext markup language).

Others have pointed out that this isnt really a language, and more of a control
codes system - and they are right. But it does give us more latitude in many ways.

Anyway, I would invite you to check out my blog, pull down the code and server (requires nodejs). I cant promise a bug-free run, as this thing continues to evolve. Im working on ditching the nodejs server requirement and moving towards hosting pages
directly on http servers, but at the moment, webservers dump the pages so quickly that the wifi modem and/or code cant keep up. I invite anyone interested to submit pull requests to help make this grow, especially from other platforms.

https://rhml-browser.blogspot.com/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2018-08-01 22:34, xlar54 : All wrote:

Hey folks, Ive been around the circuit promoting an idea Ive been
working on, to allow us with wifi enabled machines to have a web-like experience on these retro machines. They will never be able to keep up
with the ever demanding requirements of modern
day web browsing, so I believe that we can come together with other
retro enthusiasts and develop a low footprint web like protocol of our
own. Hence, my project is called RHML (retro hypertext markup language).

Others have pointed out that this isnt really a language, and more of a control codes system - and they are right. But it does give us more
latitude in many ways.

Anyway, I would invite you to check out my blog, pull down the code and server (requires nodejs). I cant promise a bug-free run, as this thing continues to evolve. Im working on ditching the nodejs server
requirement and moving towards hosting pages
directly on http servers, but at the moment, webservers dump the pages
so quickly that the wifi modem and/or code cant keep up. I invite
anyone interested to submit pull requests to help make this grow,
especially from other platforms.

https://rhml-browser.blogspot.com/

Quite nice, have to spin up njetworking on my VICE to see how it fares.

But it sure looks interesting!

---
* Origin: - nntp://news.fidonet.fi - Lake Ylo - Finland - (2:221/6)

On 08/02/2018 12:34 AM, xlar54 wrote:

at the moment, webservers dump the pages so quickly that the wifi modem and/or code cant keep up.

This seems like a modem / gateway / web server failing to me.

To me, there are two communication streams, one on either side of the
gateway (like the Wifi232). One is serial to the old computer. The
other is TCP/IP over some sort of network (wired or wireless).

I would expect that the serial side can be paused by (I think) dropping
DTR. (Maybe it's a different signal.) The point being for the (retro) computer to indicate that it is not ready to receive any more data from
the other end.

I would also expect that the TCP/IP side could similarly cause the web
server to pause sending data. I'm not completely familiar with the
mechanics of how. But I am confident that the TCP/IP client can tell
the sending web server how much buffer it has available. The idea being
that the web server's sending side should not exceed said buffer.

So rCa I feel like this problem (as I understand it) is solved. Or at
least it should be. Hence why I feel like there is a failing somewhere,
be it a bug or lack of leveraging the existing mechanisms.

The Slowloris attack comes to mind as supporting evidence that a TCP/IP
client can cause a web server to slow down. }:-)



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2018-08-02 12:08, Grant Taylor : All wrote:

On 08/02/2018 12:34 AM, xlar54 wrote:

at the moment, webservers dump the pages so quickly that the wifi modem
and/or code cant keep up.

This seems like a modem / gateway / web server failing to me.

To me, there are two communication streams, one on either side of the
gateway (like the Wifi232). One is serial to the old computer. The
other is TCP/IP over some sort of network (wired or wireless).

I would expect that the serial side can be paused by (I think) dropping
DTR. (Maybe it's a different signal.) The point being for the (retro) computer to indicate that it is not ready to receive any more data from
the other end.

Or ClearToSend (CTS) if you do 7-wire serial.

I would also expect that the TCP/IP side could similarly cause the web
server to pause sending data. I'm not completely familiar with the
mechanics of how. But I am confident that the TCP/IP client can tell
the sending web server how much buffer it has available. The idea being
that the web server's sending side should not exceed said buffer.

Yes, I think both 0 and 1 byte free at my end is a possible response to incoming packets when you have a hard time handling the incoming data
stream.

Telling the remote end you have only 1 byte left in the buffer is used
for instance when tarpitting spam sending email servers, to force them
to waste a lot of resources for every sent byte so that they are busy
creating packets for an email your server wont accept instead of
spamming others at that instance.

---
* Origin: - nntp://news.fidonet.fi - Lake Ylo - Finland - (2:221/6)

On 08/02/2018 03:30 PM, Janne Johansson wrote:

Or ClearToSend (CTS) if you do 7-wire serial.

*nod*

Yes, I think both 0 and 1 byte free at my end is a possible response
to incoming packets when you have a hard time handling the incoming
data stream.

:-)

Telling the remote end you have only 1 byte left in the buffer is used
for instance when tarpitting spam sending email servers, to force them
to waste a lot of resources for every sent byte so that they are busy creating packets for an email your server wont accept instead of spamming others at that instance.

Yep.

Of course that does rely on them following the rules. Something I've
learned not to rely on. But it will make things less than graceful on
their end when the do try to break the rules. But, hey, that's their
problem. }:-)



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

I have another branch on the github repo where it makes a call to a webserver if you guys would be able to help. This would be an ideal setup since people could host their RHML files along side their normal websites.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2018-08-01 22:34, xlar54 : All wrote:

Hey folks, Ive been around the circuit promoting an idea Ive been
working on, to allow us with wifi enabled machines to have a web-like experience on these retro machines. They will never be able to keep up
with the ever demanding requirements of modern
day web browsing, so I believe that we can come together with other
retro enthusiasts and develop a low footprint web like protocol of our
own. Hence, my project is called RHML (retro hypertext markup language).

Others have pointed out that this isnt really a language, and more of a control codes system - and they are right. But it does give us more
latitude in many ways.

Anyway, I would invite you to check out my blog, pull down the code and server (requires nodejs). I cant promise a bug-free run, as this thing continues to evolve. Im working on ditching the nodejs server
requirement and moving towards hosting pages
directly on http servers, but at the moment, webservers dump the pages
so quickly that the wifi modem and/or code cant keep up. I invite
anyone interested to submit pull requests to help make this grow,
especially from other platforms.

https://rhml-browser.blogspot.com/

For the client source builds, on unixlike OS:es instead of the BAT
files: (hopefully the wrap will not break the long lines)

$ more Makefile

all: browser64.prg browser128.prg

browser64.prg: browser.c userial.c nmi_trampoline.s
cl65 -O -t c64 browser.c userial.c nmi_trampoline.s -o browser64.prg

browser128.prg: browser.c userial.c
cl65 -O -t c128 browser.c userial.c -o browser128.prg

install: all
cp browser64.prg ../client/c64/browser64.prg
cp c64-* ../client/c64/
cp browser128.prg ../client/c64/browser128.prg
cp c128-* ../client/c128/

clean:
-rm -f *.prg
-rm -f *.o
-rm -f *.o65
-rm -f ../client/c128/*
-rm -f ../client/c64/*

---
* Origin: - nntp://news.fidonet.fi - Lake Ylo - Finland - (2:221/6)

On Monday, August 6, 2018 at 10:38:14 AM UTC-5, Janne Johansson wrote:

On 2018-08-01 22:34, xlar54 : All wrote:

Hey folks, Ive been around the circuit promoting an idea Ive been
working on, to allow us with wifi enabled machines to have a web-like experience on these retro machines.-a They will never be able to keep up with the ever demanding requirements of modern
day web browsing, so I believe that we can come together with other
retro enthusiasts and develop a low footprint web like protocol of our own.-a Hence, my project is called RHML (retro hypertext markup language).

Others have pointed out that this isnt really a language, and more of a control codes system - and they are right.-a But it does give us more latitude in many ways.

Anyway, I would invite you to check out my blog, pull down the code and server (requires nodejs).-a I cant promise a bug-free run, as this thing continues to evolve.-a Im working on ditching the nodejs server
requirement and moving towards hosting pages
directly on http servers, but at the moment, webservers dump the pages
so quickly that the wifi modem and/or code cant keep up.-a I invite
anyone interested to submit pull requests to help make this grow, especially from other platforms.

https://rhml-browser.blogspot.com/

For the client source builds, on unixlike OS:es instead of the BAT
files: (hopefully the wrap will not break the long lines)

$ more Makefile

all: browser64.prg browser128.prg

browser64.prg: browser.c userial.c nmi_trampoline.s
cl65 -O -t c64 browser.c userial.c nmi_trampoline.s -o browser64.prg

browser128.prg: browser.c userial.c
cl65 -O -t c128 browser.c userial.c -o browser128.prg

install: all
cp browser64.prg ../client/c64/browser64.prg
cp c64-* ../client/c64/
cp browser128.prg ../client/c64/browser128.prg
cp c128-* ../client/c128/

clean:
-rm -f *.prg
-rm -f *.o
-rm -f *.o65
-rm -f ../client/c128/*
-rm -f ../client/c64/*

Oh wow thank you!

Side, note: the issues with the webserver branch have been corrected. It works well, but theres a few more things I need to do to make it 100%. Stay tuned. It would be ideal for us to be able to host both html pages for web users, and rhml pages for
retro users.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)