OpenXTalkPaul wrote: ↑Sat Feb 08, 2025 3:59 am
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.