Neon (Demo) - Hypertext (ADF) Browser for Atari

[Gibstov]

2 minutes ago, x=usr(1536) said:

Understood so far.

The short answer is, "it should work".  I'll come back to this after the next question, since parts of the answer tie into that question as well.

I think I see what you're getting at here.  In this particular case, I'm leaning towards absolute TNFS URIs being necessary.  Here's why:

 

Consider for a moment how a browser determines whether a link is relative or absolute: it retrieves a remote HTML file, examines it for rendering, and notes the absolute location of that specific file on the remote server.  When a link in that file is followed, it is compared with the file's absolute location and a determination is made as to whether or not the link is absolute or relative.

 

TNFS operates differently in that it has no knowledge of the file's contents - it just reads or writes it as appropriate without parsing its contents.  As such, all TNFS URIs can be considered absolute because there's no good way to determine a path relative to the file's location from the contents of file itself by the TNFS client.  This is where I earlier alluded to TNFS being more like FTP than HTTP: even though both FTP and HTTP perform file transfers from a remote host to a local client, FTP doesn't examine and/or act upon the file's contents - much like TNFS.

 

As this relates to Neon: because Neon would be running on top of TNFS (i.e., just using TNFS to transport files to or from the Neon client), Neon would have the same addressing limitations as TNFS would.  Thus, no relative links in Neon.

 

One thing I will add is that TNFS respects URIs with absolute paths that traverse directories - so URIs containing the '..' shorthand to change up a level will be processed correctly.  Symlinks also seem to be handled correctly, but that's more a filesystem-level concern.  Either way, neither one really gets you where you want to be; just decided to mention them for completeness.

 

FWIW, TNFSD is pretty lightweight, by which I mean that simplicity seems to be favoured over features.  Not a huge deal, but it does mean that in order to do things like have a welcome message on the root of the TNFS server, you have to create a zero-length file where the filename is the (very brief) message you want to display when someone accesses that directory.  There's no concept of an index.html or similar.

Nifty, and good to hear.

It occurred to me after I wrote that that TNFS does have its own analogy to the PUT method via the copy feature.  But for something like a form, you'd have to edit it on the client, recompile, then upload rather than just sending the data back for processing.  Not ideal.

 

Sorry just so we are on the same page here as regards to relative links.  As far as N: device or any device is concerned, it would be given the full address/filespec.  So in the example where someone clicked on a link, for example "Example2.DOC", as far as FujiNet is concerned, Neon would send it "N:tnfs://my-test-server/NeonTest/Example2.DOC.".  So relative links are handled by Neon, by keeping its own path and the inserting it where needed.

 

So I am thinking that it should work, or am I still missing something?

 

 

 

[+x=usr(1536)]

2 hours ago, Gibstov said:

Sorry just so we are on the same page here as regards to relative links.  As far as N: device or any device is concerned, it would be given the full address/filespec.  So in the example where someone clicked on a link, for example "Example2.DOC", as far as FujiNet is concerned, Neon would send it "N:tnfs://my-test-server/NeonTest/Example2.DOC.".  So relative links are handled by Neon, by keeping its own path and the inserting it where needed.

 

So I am thinking that it should work, or am I still missing something?

Nope, that should work.  Apologies for the misunderstanding.

[Gibstov]

20 minutes ago, x=usr(1536) said:

Nope, that should work.  Apologies for the misunderstanding.

Awesome, thanks for the clarification.

[Gibstov]

An example of using :NAME and a quick note about #ID

 

The command :NAME allows you to assign a memory address to an #ID.  

 

Also, though it is not documented, the #ID FF is reserved. #ID FF is assigned the value of $E000 (the address of the built in character set).

 

In this example, :NAME is used to view the international char set ($CC00) and then using #ID FF to switch back to the default char set.

 

; Use :NAME to display international charset
; #ID FF is reserved and used to refer to default charset E000

:head
:name #id f1 %sz CC00 ;%sz is memory address to assign to #ID
:code #id c1 #ws 1 #CH FF ;set CHBASE to databank FF (E000)
:page #ch f1 ;set CHBASE to databank f1 (CC00) international charset
:text

Example of using the international 
charset

Spell words like jalape[ctrl-b]o or attach[ctrl-u]

Or an 80's Hairband
M[ctrl-o]tley Cre[ctrl-j]
:fill #mb 70 ;insert some blank lines
:call #id c1 ;switch back to default charset
:text

| Set attribute #CH to FF to switch |
| back to the default charset       |

:fill

Edited July 13, 2021 by Gibstov

[danwinslow]

Now THIS is pretty cool. Nice. I'll have to finally set up my Fuji.

[_The Doctor__]

deleted, I need to play with this a little then I'll pm you

Edited August 3, 2021 by _The Doctor__

[mozzwald]

I just gave it a quick run through of the examples and this is looks quite awesome

On 7/11/2021 at 1:20 PM, x=usr(1536) said:

This opens the door to things like an ADF daemon handling page compilation on a *nix box acting as the server

On 7/12/2021 at 9:44 AM, Gibstov said:

It should be fairly straight forward to port the Neon Compiler (Make) to other platforms (famous last words), because the program is written in C.

When I saw this program and what it is able to do, I immediately thought of a stripped down web browser for Atari with a server handling HTML to ADF conversion and feeding the data with FujiNet. I did some playing around with FrogFind and converting HTML to Markdown to ATASCII. I think converting to ADF would be much more amazing with the use of graphics. So, if you can make compiler that runs on linux, do share  

On 7/12/2021 at 9:44 AM, Gibstov said:

Maybe in the future, I was thinking that Form elements could be added.  Kind of using the same frame work, maybe moving the joystick will move the focus to the various controls.  Click the button on the control to change its value.  Though I imagine the way this would work is it would save the Form values as a file. 

Input form would be useful for web browser  I envision a portal page like the FrogFind search engine and send the form results back to the server using the N: device.

 

[Mr Robot]

No one mentioned that ADF files are Amiga Disk File's yet? This is going to get really confusing for retro fans who aren't just into Atari. 

 

Atari Hypertext Format (AHF) or Atari Hypertext Language (AHL) are unused (AHL was used by eMule but thats no more) Atari Hypertext Document (AHD) is in use by Microsoft as a type of help file.

 

Aside from that, I'm looking forward to writing some pages in this  

 

[Gibstov]

13 hours ago, mozzwald said:

I just gave it a quick run through of the examples and this is looks quite awesome

When I saw this program and what it is able to do, I immediately thought of a stripped down web browser for Atari with a server handling HTML to ADF conversion and feeding the data with FujiNet. I did some playing around with FrogFind and converting HTML to Markdown to ATASCII. I think converting to ADF would be much more amazing with the use of graphics. So, if you can make compiler that runs on linux, do share  

Input form would be useful for web browser  I envision a portal page like the FrogFind search engine and send the form results back to the server using the N: device.

 

Neon is basically two programs the compiler and the reader.  The compiler part could be separated out and run on the Fuji device, and then the reader part could then run on the Atari side.  The only Atari specific code in the compiler is just the CIO routines to read from the disk, so it should be able to be ported to Linux.  I'll look into putting it up on GitHub or another repository, or at least sharing it with you.

 

As far as input is goes, I was thinking of creating a number of form elements, Atari style: radio buttons, checkboxes, buttons, text fields, etc.  And then saving it to a file as a series of records.  Suppose the file it was saving it to was on the N: device.  Then maybe the Fuji device could process that file.  I haven't fully thought through how it could work.

 

 

[Gibstov]

13 hours ago, Mr Robot said:

No one mentioned that ADF files are Amiga Disk File's yet? This is going to get really confusing for retro fans who aren't just into Atari. 

 

Atari Hypertext Format (AHF) or Atari Hypertext Language (AHL) are unused (AHL was used by eMule but thats no more) Atari Hypertext Document (AHD) is in use by Microsoft as a type of help file.

 

Aside from that, I'm looking forward to writing some pages in this  

 

Maybe a compromise: Use either ADF/AHF as an extension.

 

[massiverobot]

3 hours ago, Gibstov said:

Maybe a compromise: Use either ADF/AHF as an extension.

 

I like AHF, and I second @Mr Robot note about Amiga- the ADF format is wide and deep. Just google it Best not to compete at this point.

 

You don't need to use TNFS to store AHF docs- you should be able to put them on any http/s webserver and pull them right in with the N: device.

 

See the work @tschak909 helped me with to load a BASIC file right from HTTPS into TurboBasic.

 

I would imagine the same thing could be done in the AHF Application - just load in N: device driver at boot and start to pull down real URIs that contain valid AHF files... and you just go!

 

Using RastaConverter on the server side to translate images on the fly would be... fly!

 

 

Amazing job @Gibstov this is a really cool project and it's hitting at just the right time!

 

[Gibstov]

22 minutes ago, massiverobot said:

I like AHF, and I second @Mr Robot note about Amiga- the ADF format is wide and deep. Just google it Best not to compete at this point.

 

You don't need to use TNFS to store AHF docs- you should be able to put them on any http/s webserver and pull them right in with the N: device.

 

See the work @tschak909 helped me with to load a BASIC file right from HTTPS into TurboBasic.

 

I would imagine the same thing could be done in the AHF Application - just load in N: device driver at boot and start to pull down real URIs that contain valid AHF files... and you just go!

 

Using RastaConverter on the server side to translate images on the fly would be... fly!

 

 

Amazing job @Gibstov this is a really cool project and it's hitting at just the right time!

 

Thanks...I was hoping that it could be useful.

 

Just to clarify some points to make sure everyone is on the same page.  There are two file types: The ADF file is source code useful for developers.  The DOC file is the compiled document for the end user.  So in the instance of serving files from a webserver, I think it should be serving the DOC files directly to Neon.  So for instance in Neon, you would choose R for read. 

And then enter in something like: N:http://www.mysite.com/welcome.doc

 

Now for dynamic pages, I could see maybe creating a compiler on the webserver that takes an ADF/AHF file and then compiles it to a DOC file before sending it to Neon.

 

As far as switching the file extension from ADF to AHF I am not opposed to it, but  keep in mind, Neon doesn't really care about the extension.  My only reservation about changing the extension is that I have rewrite all the documentation.  Which I am not opposed to, but it would be a lower priority.

 

 

 

 

[massiverobot]

11 minutes ago, Gibstov said:

Now for dynamic pages, I could see maybe creating a compiler on the webserver that takes an ADF/AHF file and then compiles it to a DOC file before sending it to Neon.

 

I imagined it would also be able to take HTML files, convert them into AHF, and _then_ convert them into DOC and send the DOC as the response back to the FujiNet.

 

This use case would be for more dynamic things like having a search function that uses Google for a user-input search term, and then spits out DOC to the Atari- all server side. See the FrogFind project that does exactly this to dumb-down modern HTML for older non-JS/CSS browsers.

 

 

Quote

As far as switching the file extension from ADF to AHF I am not opposed to it, but  keep in mind, Neon doesn't really care about the extension.  My only reservation about changing the extension is that I have rewrite all the documentation.  Which I am not opposed to, but it would be a lower priority.

 

I suggest only that in the future, trying to search for AHF will return much better results than someone trying to search for ADF and expect to get back hits for this project.

 

Edited August 5, 2021 by massiverobot

[Gibstov]

13 minutes ago, massiverobot said:

 

I imagined it would also be able to take HTML files, convert them into AHF, and _then_ convert them into DOC and send the DOC as the response back to the FujiNet.

 

This use case would be for more dynamic things like having a search function that uses Google for a user-input search term, and then spits out DOC to the Atari- all server side. See the FrogFind project that does exactly this to dumb-down modern HTML for older non-JS/CSS browsers.

 

 

I suggest only that in the future, trying to search for AHF will return much better results than someone trying to search for ADF and expect to get back hits for this project.

 

OK...I see what you are saying.  I was thinking of files created specifically for Neon, like our own Atari Fuji sites.  And you are referring to taking existing web pages and converting that to AHF, and then to DOC to be viewed in Neon.  I think I am tracking now.

 

So basically pull the Reader part out of Neon...as the web browser to run on the Atari.  The compiler part, runs on the Fuji device, and then compiles the source file to a doc.  And the web server just serves HTML.

 

So in the Reader, I would put in something like: N:http://www.mysite.com/welcome.html

 

Then on the Fuji device it runs FrogFind or our new application that converts the HTML to AHF.  The compiler then converts the AHF to a compiled DOC, before then sending it to Neon who just thinks it is a DOC file and loads it.

 

 

 

Edited August 5, 2021 by Gibstov

[massiverobot]

28 minutes ago, Gibstov said:

OK...I see what you are saying.  I was thinking of files created specifically for Neon, like our own Atari Fuji sites.  And you are referring to taking existing web pages and converting that to AHF, and then to DOC to be viewed in Neon.  I think I am tracking now.

 

So basically pull the Reader part out of Neon...as the web browser to run on the Atari.  The compiler part, runs on the Fuji device, and then compiles the source file to a doc.  And the web server just serves HTML.

 

So in the Reader, I would put in something like: N:http://www.mysite.com/welcome.html

 

Then on the Fuji device it runs FrogFind or our new application that converts the HTML to AHF.  The compiler then converts the AHF to a compiled DOC, before then sending it to Neon who just thinks it is a DOC file and loads it.

 

 

Yes! Essentially, you have created a "Web Browser" called Neon for the Atari!

 

All DOC files should be available on the web, somewhere, at a standard HTTP URI.

 

As content creators start to convert their documents to AHF, they will need some program to feed in some format (HTML?) and output AHF.

 

Creators can also create AHF documents from scratch, just using a text editor.

 

They would then just push these AHF files up into the web, on some web server.

 

 

Meanwhile, we develop a PHP application that incorporates your AHF->DOC code. This PHP app will take HTTP requests from the Fujinet, but originated on the Neon app on the Atari. The FN and N: device are doing all the NEON URI -> HTTP/S heavy lifting to handle the HTTP/S connection to the PHP application living on some server somewhere in the cloud.

 

The PHP just gets the HTTP/S request from the FN, finds the proper DOC file on it's local file system. If the DOC files does _not_ exist, it reads the corresponding AHF file and converts it to DOC and sends the DOC file back as a HTTP Response to the FN. Now the DOC is created, it stays, cached on the server to be served the next time it's requested by a Neon/FN.

 

The PHP app would also look at the timestamp on the AHF file, and if it's changed, it would re-created the DOC file at next request for it.

 

So, in my mind the flow is like:

 

Request:

NEON->N:->FN->HTTPS->WEBSERVER->PHP->DOC|AHF=> RESPOND with DOC

 

Dynamic Request:

NEON->N:->FN->HTTPS->WEBSERVER-PHP->Proxy to "external HTML file"->[Convert HTML to AHF->Convert AHF to DOC]-> Respond with DOC file

 

The PHP application 'knows' if the request is internal or external based on the URI path...

 

 

This is very very cool, so many possibilities.

 

 

Edited August 5, 2021 by massiverobot
put in N: device

[massiverobot]

Also, this would be a very cool use for the HELP key for XL/XE computers!

 

Imagine Neon version that is patched to catch the HELP key being pressed....

 

It is configured, if Neon is running, to pull down a defined "Help Page" with all the starter links for Neon- so people don't have to guess where to go for help!

 

 

Or even deeper integration, if N: device itself is patched, to catch HELP being pressed at any time, and somehow go out and mount and run the Neon ATR and then pull down a help file... Not sure if this makes sense, but the idea is interesting.

 

[+x=usr(1536)]

14 minutes ago, massiverobot said:

Also, this would be a very cool use for the HELP key for XL/XE computers!

 

Imagine Neon version that is patched to catch the HELP key being pressed...

I fully support and endorse the idea of using the HELP key; it was severely under-utilised back in the day.

 

So, any suggestions for how to accommodate 400/800 owners?

[massiverobot]

1 minute ago, x=usr(1536) said:

So, any suggestions for how to accommodate 400/800 owners?

Yes, but it involves the TK-2

https://ataribits.weebly.com/tk-ii.html

 

Install TK-ii on your 800, use the Mapped HELP key on your PS/2 keyboard (which is F1).

 

That is my first thought on how to handle it.

[Gibstov]

38 minutes ago, massiverobot said:

Also, this would be a very cool use for the HELP key for XL/XE computers!

 

Imagine Neon version that is patched to catch the HELP key being pressed....

 

It is configured, if Neon is running, to pull down a defined "Help Page" with all the starter links for Neon- so people don't have to guess where to go for help!

 

 

Or even deeper integration, if N: device itself is patched, to catch HELP being pressed at any time, and somehow go out and mount and run the Neon ATR and then pull down a help file... Not sure if this makes sense, but the idea is interesting.

 

That is not a bad idea.   I was actually thinking about using HELP for a different purpose.  Right now DOC files are limited to 16K and fit right in the bank switchable region ($4000-$7FFF).  So for owners of an Atari 130XE, or other systems with extended RAM, I was thinking you could have multiple documents open in different "tabs", and could switch between them using HELP.  Or maybe use HELP for links and OPTION to switch between tabs.  Not sure what the demand is, just an idea that I had.

 

[massiverobot]

4 minutes ago, Gibstov said:

Right now DOC files are limited to 16K and fit right in the bank switchable region ($4000-$7FFF). 

 

Ha, ok. I'm imagining there is a lot you can fit into 16k DOC file. Looking forward to test the limits soon.

[mozzwald]

1 hour ago, Gibstov said:

And you are referring to taking existing web pages and converting that to AHF, and then to DOC to be viewed in Neon

exactly

1 hour ago, Gibstov said:

So basically pull the Reader part out of Neon...as the web browser to run on the Atari.  The compiler part, runs on the Fuji device, and then compiles the source file to a doc.  And the web server just serves HTML.

Not exactly. I think it'd be better to have the compiler on a web server that takes the HTML and coverts to AHF then to DOC and pass the DOC to FujiNet (all on the fly). Fujinet knows nothing other than it's passing an HTTP(S) request. Caching could be added down the road, but I don't really expect this to be needed. We are just converting text here after all  

 

Check out the FujiFind page I made using FrogFind and you can see it strips out all the garbage (CSS/javascript/etc) and gives you plain text of a webpage. I see a portal like this (in AHF/DOC) that converts everything for you on the fly, server side. The very lame BASIC program I made (networking/www.atr on fujinet.online tnfs) pulls from a modified version of FujiFind that converts the HTML to Markdown to ATASCII. An example wikipedia page in ATASCII is here. If we can get all the pieces together, I suspect we can do the same for HTML to AHF to DOC using PHP.

 

Perhaps images could be added down the road with a link to view image and have it converted on the fly also. @billkendrickis converting the astronomy picture of the day in PHP with his APOD viewer for Atari/Fujinet. We could take some cues from that

[Gibstov]

9 minutes ago, mozzwald said:

exactly

Not exactly. I think it'd be better to have the compiler on a web server that takes the HTML and coverts to AHF then to DOC and pass the DOC to FujiNet (all on the fly). Fujinet knows nothing other than it's passing an HTTP(S) request. Caching could be added down the road, but I don't really expect this to be needed. We are just converting text here after all  

 

Check out the FujiFind page I made using FrogFind and you can see it strips out all the garbage (CSS/javascript/etc) and gives you plain text of a webpage. I see a portal like this (in AHF/DOC) that converts everything for you on the fly, server side. The very lame BASIC program I made (networking/www.atr on fujinet.online tnfs) pulls from a modified version of FujiFind that converts the HTML to Markdown to ATASCII. An example wikipedia page in ATASCII is here. If we can get all the pieces together, I suspect we can do the same for HTML to AHF to DOC using PHP.

 

Perhaps images could be added down the road with a link to view image and have it converted on the fly also. @billkendrickis converting the astronomy picture of the day in PHP with his APOD viewer for Atari/Fujinet. We could take some cues from that

OK..yeah...it probably makes more sense to run the compiler on the web server, and just serve the resulting DOC to Fujinet/Neon.

 

The major constraint I see with converting HTML pages into the resulting ADF/AHF or DOC files is there isn't any scrolling facility in Neon.  Since one of the design goals for this project was being able to use DLIs, that causes major headaches if the page scrolled down (for instance what happens if a line with a DLI is scrolled off the page).  So everything needs to fit on one screen and use navigation to switch pages.

 

 

[massiverobot]

6 minutes ago, Gibstov said:

The major constraint I see with converting HTML pages into the resulting ADF/AHF or DOC files is there isn't any scrolling facility in Neon.  Since one of the design goals for this project was being able to use DLIs, that causes major headaches if the page scrolled down (for instance what happens if a line with a DLI is scrolled off the page).  So everything needs to fit on one screen and use navigation to switch pages.

 

 

 

Ok, so the PHP/AHF -> DOC Application would take the source AHF and just pre-page it up into as many single pages as required from the source AHF doc size...

 

And it would include NEXT/PREV Links with each 'page' - So think of this more like HyperCard, with a Stack, than a scrolling webpage.

 

Neon would just map NEXT/PREV with a set of key(s).

 

Everything else just works as stated by @mozzwald This will help as it will also maintain the 16k DOC files limit.

 

I loved working with Hypercard Stacks....

 

 

Edited August 5, 2021 by massiverobot
speling

[Gibstov]

4 minutes ago, massiverobot said:

 

Ok, so the PHP/AHF -> DOC Application would take the source AHF and just pre-page it up into as many single pages as required from the source AHF doc size...

 

And it would include NEXT/PREV Links with each 'page' - So think of this more like HyperCard, with a Stack, than a scrolling webpage.

 

Neon would just map NEXT/PREV with a set of key(s).

 

Everything else just works as stated by @mozzwald This will help as it will also maintain the 16k DOC files limit.

 

I loved working with Hypercard Stacks....

 

 

Yeah sounds good.

 

But instead of mapping Keys, it would need to insert two links at the bottom of the page. (:LINK) 

 

:text
<-PREVIOUS    NEXT->
:link $li "Page1" #ML 0 #MR 9 ;use #ml,#mr to control inverse
:link $li "Page3" #ML E #MR 13 ;use #ml,#mr to control inverse  

 

[mozzwald]

16 minutes ago, Gibstov said:

insert two links at the bottom of the page. (:LINK) 

 

1 hour ago, Gibstov said:

Right now DOC files are limited to 16K

This could get tricky depending on the size of the web page being converted. Large pages (and if we add images) will need to be handled differently somehow