On Wed, Dec 28, 2022 at 2:20 PM Bert Put <b...@bertput.com> wrote: > Hi John, > > I hope you make it generic enough for us NAS users to be able to use it; > a Synology (for instance) could make itself visible on the interwebs > without you needing to forward a port on your router from the outside; > it all relies on Synology's servers being up. > > Since I don't do "social media" I try to stay off of google, FB, MS, and > all those other funny acronyms 😄 > > Regards, Bert > > Currently CloudT is a static website. It provides a single page application of HTML, Javascript and CSS all in one shot... the cloud server doesn't maintain any memory (beyond log files) of you or store anything about you or your files. What storage there is is in your browser and in your own Google Drive account (if you use that feature).
As much as possible I want to keep it that way. It's funny, Model T programs are sometimes small enough that they could be encoded and embedded in a URL directly in their entirety. But in the general case, not quite small enough. Recommendations for a URL size seem to limit at about 2,000 bytes. Model T programs can be and RAM images certainly are bigger than that. Same order of magnitude, but not big enough. So to facilitate sharing of programs, RAM images possibly bundled with config/launch instructions, the bundles need to be published on the web. Google Drive supports sharing content via URL. HTTP, HTTPS, FTP servers were of course built for that though I think most people don't want the hassle of managing their own servers, even with something like WebDAV which in my experience can be a pain. Another store might be Github links or similar... since then your URL could always provide a link to your current hopefully least buggy version. Anyway, the first thing would be to come up with a encoding and structure for the URL. Like bitchin100.com/CloudT?app=<encoded URL of manifest file> The manifest file would have a list of files and machine readable launch instructions. Cloud T would load from bitchin100. Then inside the browser, the javascript code would go get the manifest file, pull each component and then run simple launch instructions to inject into the emulation and start the program. Bitchin100 CloudT wouldn't then need to store anything. It would all be up to the person sharing their program to publish a manifest file and component files. All that would have to happen is CloudT would need to learn the manifest format, implementing javascript to GET it, GET files it points to, inject and launch. -- John.
