The mane problem is the lack of ifdef in Java.  The mane WebServer.java class has 34 java includes & 5 android includes, but no easy way to swap out the android includes.  This depends on Stuff.java which is android heavy.  This was leaning towards a new platform class with wrappers for all the android bits or maybe making Stuff.java platform specific.  WebServer.java is such a mess, replicating it in its entirety would not be ideal.  Http is quite a mess, being a text protocol that mixes binary data with natural language, carriage returns, linefeeds, many different encodings of the same characters.

Having said that, WebServer.java is actually partially replicated in Ultramap https://github.com/heroineworshiper/ultramap.  The ultramap version is much simpler since it doesn't have full file management.

android.text.Html.fromHtml would be quite difficult to replicate in Java SE.  It was quite a struggle to translate between the many html character codes, but there could be a reduced functionality.  If only the test cases for that function were still around.

With most filesystem based devices, lions are just using NFS.  Only the raspberry pi zeros absolutely need a browser file manager.  Wifi isn't up to NFS, but those devices just aren't seeing any use.  They amount to 2 sound recorders.  Maybe they would see more use if they had a browser file manager, but they also need a way of announcing their IP addresses.  It typically involves getting in on a serial console & running ifconfig, in which case you might as well use scp.  Webphone works on a phone because phones can show their IP address & getting a console is a pain.  What might work is a good old browser bookmark, but a PC browser isn't the only client for webphone.

Webphone would allow a phone browser to manage & download files on all the embedded devices instead of just the sound recorders.  That could be a win.

The 1st step might be abstracting the android dependencies in the android version & testing it in android.

------------------------------------------------------------------------------------------------------------------------

It seems android.text.Html.fromHtml just converts an html string from the upload textbox:

What ＊is＊ the wavefunction？.mp4

Into a string for java.io.File where the \&\#65290\;  is converted to charAt() value 65290

When it goes the other way, it uses its own encodeHtml function to convert the charAt values to &#; strings.  This function came from grok.

Helas, if A HREF points to a $#; encoded string, the browser doesn't send a GET request.  Neither can the browser handle % unicode encodings in the A HREF.  It only converts spaces to %20.  Fortunately, there was never a desire to download a funky filename using webphone.  The funky filenames play properly in the android programs.

---------------------------------------------------------------------------------------------------

Many grok prompts later, the standalone version was working.

The PC's filesystem could be accessed on the phone.  Pretty clumsy on a phone browser.  It defaults to a ridiculously small font & large textbox size for the editor even though it's fine on the PC browser.