Not working as expected?
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Livecode Opensource Backer
- Posts: 9444
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Not working as expected?
That was a marvellous explanation that cleared up any
doubt about what you meant previously.
Thank you.
doubt about what you meant previously.
Thank you.
-
- VIP Livecode Opensource Backer
- Posts: 346
- Joined: Mon Mar 01, 2010 7:13 pm
- Location: London, UK
- Contact:
Re: Not working as expected?
Now that is a helpful expansion on the topic, with a capital 'helpful'! Thank you
Re your linked-to post, that's also a very good, clear-eyed analysis. It could be an interesting backroom (possibly sophomorish) debate looking at the sometimes significant differences between desktop and mobile in the light of your notes about the big (big, big) differences between desktop and web. But more in the 'over beers' sense than anything more.
Salut.
k
Re your linked-to post, that's also a very good, clear-eyed analysis. It could be an interesting backroom (possibly sophomorish) debate looking at the sometimes significant differences between desktop and mobile in the light of your notes about the big (big, big) differences between desktop and web. But more in the 'over beers' sense than anything more.
Salut.
k
Technical Writer, Meta
University Lecturer
Technical Editor, MacUser (1996-2015)
360 VR media specialist
University Lecturer
Technical Editor, MacUser (1996-2015)
360 VR media specialist
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Not working as expected?
There's MUCH more than "over beers" stuff at the end of that post I linked to.
I'll reiterate it here just to shout it from the rooftops for the 101st time over the last couple decades, because I really do think it's valuable, and sorely undervalued:
I'll reiterate it here just to shout it from the rooftops for the 101st time over the last couple decades, because I really do think it's valuable, and sorely undervalued:
For myself, even though I helped fund LC's HTML export out of curiosity, my own deployments take either of two different routes:
- use LC to help generate truly native web UIs (ad hoc variants of the Toolbook approach)
- web-savvy standalones ("streaming apps") that download UI along with content/data from the server (more or less else Adobe does these days)
The latter provides the best of both worlds for those apps worth the small cost of a one-time install. Once installed, updates happen automatically with each session, just as they do on the web, but with a much richer UI fully dedicated to the task the app was built for, and with full OS integration including file access, registry, IAC, etc.
Streaming apps are perhaps the greatest untapped potential in our community.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Not working as expected?
Very interesting discussion.
I personally prefer not to use web apps but increasingly these are viewed as the preferred 'thin client' in our work environment and after a few discussions with higher-ups in IT, this is very much the preferred direction of travel from their corporate perspective.
I very much like the idea of streaming apps, but i suspect actually implementing this in a secure, rock solid fashion may be a stumbling block for many.
Is this something LiveCode could make an infrastructure and API for? (obviously could be costed service, but would have to remove all the complexity - really just include a button 'deploy' and having it running...)
It strikes me this is the kind of thing that probably needs a streamlined user-friendly implementation in LC for it to flourish...
I personally prefer not to use web apps but increasingly these are viewed as the preferred 'thin client' in our work environment and after a few discussions with higher-ups in IT, this is very much the preferred direction of travel from their corporate perspective.
I very much like the idea of streaming apps, but i suspect actually implementing this in a secure, rock solid fashion may be a stumbling block for many.
Is this something LiveCode could make an infrastructure and API for? (obviously could be costed service, but would have to remove all the complexity - really just include a button 'deploy' and having it running...)
It strikes me this is the kind of thing that probably needs a streamlined user-friendly implementation in LC for it to flourish...
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Not working as expected?
In the sense I outlined, it's been a core capability since HTTP was added, years before LC acquired the engine.
In its simplest form it's a one-liner:
Code: Select all
go url <urlToStackFile>
On the security side, see the securityPermissions global property. Turn everything off except net access and you're safer than pretty much any browser.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Not working as expected?
Simple example you already have:
In the IDE, choose Development -> Plugins -> GoLiveNet
The only thing in the plugin stack file is the loader. The window that gets loaded lives on one of my servers. The content displayed there lives on another server, with some of it aggregated from five different sites, exemplifying a simple mash-up celebration of the many ways LC can use HTTPS.
In the IDE, choose Development -> Plugins -> GoLiveNet
The only thing in the plugin stack file is the loader. The window that gets loaded lives on one of my servers. The content displayed there lives on another server, with some of it aggregated from five different sites, exemplifying a simple mash-up celebration of the many ways LC can use HTTPS.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 7257
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Not working as expected?
I use the stack download method a lot, in one case where bug fixes had to be implemented immediately while medical workers were standing in the patient room and had no time to wait for an eventual update. The stack had to be extremely secure. We used SSL exclusively with an AWS server which requires specific tokens for server queries to be executed.
In other apps SSL is usually good enough. We've never had a problem, and one desktop app has been in use for years.
In other apps SSL is usually good enough. We've never had a problem, and one desktop app has been in use for years.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Re: Not working as expected?
Ahh I see. No that’s not what I meant (I have already used that myself, only instead of an online server it’s a repository on the intranet).FourthWorld wrote: ↑Thu Aug 12, 2021 1:24 amSimple example you already have:
In the IDE, choose Development -> Plugins -> GoLiveNet
The only thing in the plugin stack file is the loader. The window that gets loaded lives on one of my servers. The content displayed there lives on another server, with some of it aggregated from five different sites, exemplifying a simple mash-up celebration of the many ways LC can use HTTPS.
It’s the terminology that is confusing. I would argue that’s not “streaming”, that’s “downloading”. When I think “streaming apps” I’m thinking of apps that are not running on the client side
Something more akin to google stadia or nvidia game streaming platform.
Basically there is no file downloaded, you’re streaming the app that is actually running on a cloud PC - and the technology is currently impressively fast allowing you to run full immersive 3D games with 80+ FPS. Benefits are you are not dependent on the hardware or OS.
But I’m guessing that’s a far cry from being feasible in LC.
Not that the approach you show has anything wrong with it at all, but calling them “streaming apps” can seem a bit misleading as they are running on the user’s system and not being “streamed”.
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Not working as expected?
True, "streaming" can mean many things.
But nomenclature aside, no file is written to disk. I suppose it could be if you want caching for offline use, but that would be true of any streaming media.
What is a streaming movie but a file accessed remotely via url? Same with "go stack...".
Movies, interactive documents...all have a zero footprint.
Indeed, many media streaming services do extensive local caching, but that need not be so with stack files.
And with securityPermissions turned off for everything but net access, you not only don't have local storage, but no local file access of any kind is allowed at all.
With the other securityPermissions preventing access to other precesses, screen shots, and more, you not only get zero footprint but a pretty good security model as well.
But nomenclature aside, no file is written to disk. I suppose it could be if you want caching for offline use, but that would be true of any streaming media.
What is a streaming movie but a file accessed remotely via url? Same with "go stack...".
Movies, interactive documents...all have a zero footprint.
Indeed, many media streaming services do extensive local caching, but that need not be so with stack files.
And with securityPermissions turned off for everything but net access, you not only don't have local storage, but no local file access of any kind is allowed at all.
With the other securityPermissions preventing access to other precesses, screen shots, and more, you not only get zero footprint but a pretty good security model as well.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn