That sounds like the best approach.

Whilst it might seem 'annoying' to not use code in download files, I think 
LiveCode still makes it easier to not have to.

It is just that you have to work a little bit harder to separate content from 
code - and parameterise the parts (using data) which you might have written 
directly in code if there wasn't such a restriction.

Of course, as Richard points out, there are still areas where 'executable code' 
has to be allowed (expressions in spreadsheets are code after all - although 
admittedly side-effect free in some sense which *might* be the start of a line 
to draw) - however I think it wise to restrict those to things which are 
created by the user in their documents - and make sure they are heavily 
sandboxed / only allow very specific actions in line with the purpose the app.

Warmest Regards,


Sent from my iPhone

> On 11 Aug 2017, at 20:21, Sannyasin Brahmanathaswami via use-livecode 
> <> wrote:
> Mark, thanks for the thorough explanation.
> I would go on record to say that "vision" for our use of such  
> post/sideloading option would fall well within th UI/UX of the existing app, 
> since, from a design point of view our goals would want it to be virtually 
> transparent.
> That said, the CMS can get a bit snakey over time, and possibly a better way 
> to go, at least in our context of wanting to add on new modules, would be to 
> bundle the LC binary/views/script into updates that would be reviewed and 
> then post download only   image-sounds-words-jsons-assets.gz bundles. unpack 
> these and then binary uses them…
> This then allow us to add more to the app without adding more  MB to the 
> package size (since these LC binaries as pure view can be as small as 50 K) 
> and then we just use side loading for what really *is* only *data*
> this would be playing it very safe, and in someways, guard against ad hoc dev 
> CMS which is too easy to do with LC 
> BR
> On 8/10/17, 9:56 PM, "use-livecode on behalf of Mark Waddingham via 
> use-livecode" < on behalf of 
>> wrote:
>    Taken from this point of view, and looking at very successful Apps 
>    (typically games) in the stores then you are probably fine if your 
>    stackfiles have data/code in them which parameterize the *existing* 
>    actions of the main app in reasonably limited ways.
>    So, for example, providing levels to a game where some parts require 
>    computations of expressions or triggering of particular events - as long 
>    as those levels are consistent with 'what the game is meant to do' (i.e. 
>    you don't make it do anything different from what it did with the levels 
>    bundled with the original submitted app). This model applies to any sort 
>    of 'content player' - language learning flash cards or lessons would be 
>    similar - you just have to be careful to make sure you don't end up 
>    expanding the ability of the main app in a way which is not directly 
>    'seeable' in the original submitted app.
> _______________________________________________
> use-livecode mailing list
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to