OXT Cloud IDE v0.00000001

[FourthWorld]

What could be done with a cloud platform that specialized in running OXT stacks?

Um... run OXT stacks and create with xTalk scripts? I mean I'm sure I could develop browser UIs with JavaScript, HTML/CSS but where's the fun in that?

I'm thinking beyond the browser here.

Sharing OXT stacks over a network is as easy (sometimes easier) as sharing web pages.

The only thing that makes it hard is attempting to do that inside the alien confines of a browser window.

And developing in a browser typically involves reloading pages

Not necessarily, since the advent of xmlHttpRequest, which ushered in the era of modern web apps. But here I'm not thinking about web tech at all.

It's not necessarily 'the cloud' (as in storing apps/files remotely) that I'm interested in here, it's piggy-backing xTalk script on top of widely available and well supported browser engines. JavaScript/WebEngines can run without 'the cloud'.

The goal clarification is helpful. Thank you. I was thrown by the thread title.

These highlights beg the question: why go to all the effort to embed a scriptable rich media engine inside of another scriptable rich media engine, when you already have a scriptable rich media engine?

Everything needed for that is in hand right now, and has been for decades. It's been right in front of us the whole time.

Exactly, web-engines are hypermedia engines, best of all they are engines that OXT doesn't need to maintain! HTML5 and WASM has made this idea more feasible than ever before.

The cloud, the web, and the browser are related, but different.

The cloud is a collaborative workflow model where local work is shareable though a server or network of servers. It often includes storage but is not limited to that role, sometimes also providing compute resources, remote agency, and a wide range of other services.

The web (as in HTTP) is one of several Internet protocols useful for exchanging data, where the data may also be UI or even code.

The browser is one specific application which uses HTTP to provide client side display of HTML pages.

My question was to better understand your goals, which of those three is your interest here.

If I understand your reply correctly, your focus is on the third of those, exploring ways to put the OXT engine inside the browser engine.

That project began as a successful crowdfunding, and has since also consumed a decade of additional payroll burn on top, and has still not completed that goal. We could explore why that's the case further if that's of interest, but perhaps the timeline speaks for itself in assessing the ROI potential of the method chosen to pursue it.

For my own needs, using the only scripting language built into browsers has allowed me to build things for that application in less than a decade, so when I need the browser specifically I just use it as it's designed.

But the other two aspects, cloud and web, have served me well within xTalk all by itself, with no need to think about a browser application at all.

I've found good utility in delivering cloud solutions as native apps built with MetaCard and LiveCode.

If (hopefully when) OXT has a Mac engine for ARM I have a project in mind which expands on this to become a sort of organizational hub, using OXT's rapid development capabilities within a UI dedicated to org tasks.

The range of collaboration and sharing tools and toys that can be made in an xTalk easily and quickly is vast. And when the engine running them is an xTalk, they can be delivered today, realizing network and cloud benefits immediately.

[OpenXTalkPaul]

OK so what you're talking about seems to be shared stacks and/or other content via some protocol over some tcp/ip port. I was basically doing that using HyperCard as CGI (with 'WebStar' sever) back when maybe 97% of people I knew didn't have any internet at all. Back then I spent many hours studying all of those many RFCs on various protocols HTTP, FTP, GOPHER, NNTP, etc. In fact I started writing my own FTP client app/stack in HyperTalk at one point. After some time I moved on to faster connection with VNC (Timbuktu) remote controlled editing, which could transfer remote files (with compression) as needed as well.

Still that's not quite collaboration-over-IP as you've touched on in your comment. That was the promise of the 'Mother of All Demos', the original 'HyperMedia" demo (which had some interesting UI concepts too) that was all about the 'live' editing collaboration over a network... sometimes called The Ultimate VaporWare!

@tPerry2x had some ideas for a collaboration system integrated into the IDE as well. maybe you two should discuss that.
That goes beyond the scope of what I had in mind for a near-term goal 'Cloud IDE".

What I had in mind with "OXT Cloud IDE" is an xTalk/xCard Editor that runs as a web app:
1) can be delivered via standard protocols (HTTPS, that port is going to not be blocked via firewall)
2) allows for retrieval and editing of content stored either locally, either directly (via user interaction and stardard HTML5 APIs) or if running within a 'wrapper' desktop app (such as Electron) or stored in 'the cloud' remotely if possible (preferably allowing for 'cross-origin' data sources).
3) I want to avoid a requirement for any sort of 'PUT'' requests or PHP back end (as HC Sim, ViperCard, etc. use), It should be 'self sufficient' in that it's able to self-hosted environment loadable from the users local storage device (run able in an Electron wrapper or similar), or hosted via a simple 'cloud storage' or a minimal web service (read as 'free as in beer') like a 'GitHub Pages' site (thinking about things like 'Geocities' here too).

So what we have in a currently available xTalk that fits that bill is OXT Emscripten Engine (which I want to try to re-compile to WebASM soon), and then there is ViperCard and/or HyperCard Simulator (which is not at all a HyperCard 'emulator' it's really xTalk via JS/HTML/CSS with a little Perl on the back end) both of which are xTalk interpreters/xCard that run within web browsers. There's been a few other similar projects over the years I believe (I guess dating back to 'LiveCard' and 'Roadster'). I like HC Sim a lot for the ease with which it allows for exapanding it's syntax. What I don't like about most of these HC inspired web app things is that they all TRY to look like late 1980s Mac Interface, and they require PHP back-end with 'cloud' uploads for remote storage of 'stacks'. I want to be able to 'upload' and 'download' new/created content directly to/from this IDE environment running in the browser (either storing the 'files' in RAM or in some virtual file-system in browser cache).

Again, one of the problems with executing this idea with the Emscripten engine port as it currently exists (and this also applies to the similarly sandboxed 'Mobile' ports of the engine as well) is that there is no Window frames for stacks.

Rather than doom-scrolling and/or screaming into the void, this morning I modified 'BUTTON' demo to work up a little Proof-Of-Concept for 'Window-Frame' widget. It didn't take much to get it semi-functional for this purpose. If you paste this control onto a card it 'adheres' itself to the stack and sets the window decorations property to empty, and it scales the stack while in edit mode (not sure you if you can even do that with a 'custom group control').

[OpenXTalkPaul]

Its a very rough semi-functional mock-up, and not at all aesthetically pleasing.

[OpenXTalkPaul]

I mentioned 'tricks' to make the excessively large JS version of the OXT Emscripten engine possibly load faster, as mentioned by Hermann Hoch years ago now.
One thing that may help with certain browser engines is to 'mark' the script element with async

Code: Select all

<script async type="text/javascript"
       src="standalone-community-8.0.0-dp-4.js">
</script>

Another great suggestion in that same discussion (https://forums.livecode.com/viewtopic.php?t=25345) was to put the Emscripten engine on CDN ( https://www.webfx.com/blog/web-design/free-public-cdns/ ) just like all of those other JavaScript libraries out there, then so long as every Emscripten 'standalone' were to use that CDN url for the Engine, the end-users Browser would only have to download the large engine file once and from then on it should reside in the users browser cache and not need to be re-downloaded for running different 'webstacks' unless we've changed something about the Emscripten engine (like recompiling it as .wasm for example).

The instructions for building the Engine with Emscripten are extremely outdated now (by about a decade), they mention using Emscripten SDK v.1.35 which I believe is on to version 4.x now.

[OpenXTalkPaul]

This is the source Emscripten syntax module that does JavaScript stuff with Extension builder, specifically EvalJavaScript and EvalJavaScriptWithArguments

https://raw.githubusercontent.com/livec ... ripten.lcb

Could be helpful to look at in making extensions targeted to when the engine is running in a browser context, for seeing how wrapping the .js code in xBuilder / xTalk-like syntax, making xBuilder language modules.

[FourthWorld]

Inspiring?
https://grapesjs.com/