Richard:
This sounds like a great way to go!

I think I’m getting that the “Splash” app downloads the executables and 
whatever media is needed, and then these are erased at the end of the session, 
so that new ones are downloaded each session? Or is it done more like the 
browser cache, where it can be emptied manually, or regularly, and then new 
stuff is downloaded if updates are available.

I’m wondering, though, if the future that Apple has in mind is the 
iOS-ification of the Mac OS so that sandboxing and downloading of added 
executables is not allowed. Kay made this comment previously. Just wondering.

Best,
Bill

> On Feb 8, 2015, at 1:59 PM, Richard Gaskin <ambassa...@fourthworld.com> wrote:
> 
> William Prothero wrote:
> 
> > Hopefully the coming HTML5 export will make it easier to integrate
> > Livecode apps into a web delivery. The main advantage of this is
> > the ease of updating the software.
> 
> The HTML output option will be a great thing for many projects, but I think 
> it's safe to say it's many months away.
> 
> In the meantime, that main benefit of instant updates is easily achievable 
> with LiveCode right now.
> 
> With HTML all code, UI, and data is downloaded over the wire.  With LiveCode 
> we can do the same by merely extending the "anchor window" (or "splash 
> stack") setup to open stacks from URLs rather than local files:
> 
>  go url "http://yourdomain/stacks/stackfile.livecode";
> 
> You can even cut the transfer time by more than half using LC's built-in gzip 
> compression:
> 
>  go decompress(url "http://yourdomain/stacks/stackfile.livecode.gz)
> 
> A majority of the projects I'm working on currently use this setup. They're 
> workgroup collaboration tools where an Internet connection is needed for the 
> data anyway, so we just extended that to download all the stacks as well.
> 
> The standalone has only enough code to find the server and download the first 
> stack.  Everything from that point on is handled in stacks that are always up 
> to date, downloaded from the server at the start of each session just like 
> HTML is.
> 
> But since we're using LiveCode, we're able to deliver all of the benefits of 
> a UI designed specifically for the task at hand, never having to ponder the 
> sorts of questions we do when we're making web apps, like "How do we handle 
> the Back button?"  And we never have to sweat browser compatibility issues.  
> The UIs we deliver are fully dedicated for the workflows they support.
> 
> I often go a year or more without having to update the client standalone, far 
> less frequent than most browser updates.  On one project we have a client app 
> that's been in use by more than 100 team members for more than two years, and 
> all the new features they're enjoying come over the wire as quickly as I can 
> upload them to the server.
> 
> And if you haven't played with the fairly recent securityPermissions global 
> property, you're in for a treat:  lock down everything except network access 
> and your client app is far more secure than most browsers.  So admins are as 
> happy with your security as the project owner is with your rapid deployment 
> and your end-users are with your app's performance and usability.
> 
> Net-savvy apps aren't the answer for every need, and there will be a place 
> for Web apps for years to come.
> 
> But if there's anything we've learned from the mobile world that we can use 
> in our desktop work, it's that OS-native apps often outperform and provide 
> better usability than cramming a UI inside of a browser window.
> 
> And with LiveCode, this is super easy to do right now.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> ambassa...@fourthworld.com                http://www.FourthWorld.com
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to