JavaScript + LC HTML5 = LiveCode.js

[Richard Gaskin]

Matt Maier wrote:

 > On Fri, Nov 25, 2016 at 8:02 AM, Richard Gaskin wrote:
[a bunch of stuff too long to quote but available at:
<http://lists.runrev.com/pipermail/use-livecode/2016-November/232938.html>]

 > Richard,
 > Thanks for that explanation. I've heard you mention this setup several
 > times before but this is the most detail I've seen you put in one
 > place.

Thanks for the feedback.  Glad it was helpful.

 > Clarification question: do you cache the last stacks downloaded in
 > case the user isn't connected to a network?

Not currently, at least not for stacks.

Where I use "streaming apps" the requirements are often very similar to 
what we need from web apps, involving lots of data communication with 
the server.  If we don't have a connection there's little meaningful 
work that these apps can do, so I haven't bothered with an offline mode 
for them.

I do, however, have a data cache for one of these apps.  That one's a 
CMS for specialized medical content, and the time our editors can spend 
on a document can be long, often spanning many days.  To ensure the 
content isn't lost between sessions we use a check-out/check-in system 
in which the checked-out document is stored in a local cache until it's 
checked back in and safely confirmed on the server.

I could extend the cache subsystem to handle stacks as well, but thus 
far I haven't needed it.


Tip:  if you need to cache stacks you can make that super-easy by 
accompanying each stack file on the server with a small manifest-like 
text file that contains the build number of the most recently-posted 
stack.  So on the server you might have something like:

   somestack.livecode
   somestack.info

...where the *.info file contains essential metadata.

With that you can quickly compare the version/build number of a local 
stack file (stored in a custom property; I tend to use "ufwVersion" but 
the key could be any memorable string) with what's on the server with a 
super-fast download of that small text file.

I use a simple metadata file for the auto-update feature in my 
devolution plugin and some of my apps:
<http://fourthworld.com/products/devolution/index.html>

While most of my stuff includes a human-optimmized version number for 
the About box, I generally maintain an integer build numbers so version 
comparisons are dirt simple.

Even simpler:  you can have your uploading or standalone manager 
auto-increment your build number whenever you post, so you set it up 
once and never need to think about it again.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com