Sample Stacks Stack in Livecode 8 - Gone ?

Richard Gaskin ambassador at fourthworld.com
Fri Mar 18 16:26:15 EDT 2016


Mark Wieder wrote:
 > On 03/18/2016 07:24 AM, -hh wrote:
 >> Salut Rolf and Peter,
 >>
 >> I prefer also the "old" stack (of Elanor?), so I use on LC 8 the
 >> following, what is at least 10 times faster than 'livecodeshare'.
 >>
 >> on mouseUp
 >>    put specialFolderPath("engine") into p
 >>    set itemdel to slash
 >>    put "Tools/Toolset/palettes/revonline.rev" into last item of p
 >>    set itemdel to comma
 >>    palette stack p
 >> end mouseUp
 >>
 >> The stack looks really good in LC 8 with native theme ;-)
 >
 > Interesting. That's *so* much nicer than the web page. Still some
 > problems with that stack, as in the scrollbar doesn't seem to work
 > and sometimes the page selectors don't show anything, etc.

Curious that it's still in the install but made inaccessible/unusable. 
If it's being deprecated why not just pull it?


 > ...and I notice that it's no longer possible to upload stacks to
 > revOnline/LiveCodeShare :( "Share This Stack" is no longer on the LC8
 > menu). Bug 17176 filed.

Followed.  It'll be interesting to learn the intent with this.

A thing like RevOnline is at once very empowering and very dangerous:

One the one hand LC's ability to download-and-run stack files is 
absolutely awesomely powerful and fun.

But on the other hand that power also means that someone with poor 
manners could upload malware, using the full power of the LiveCode 
language to the downloader's disadvantage.

I pulled stack uploads out of RevNet for that reason long ago (Note for 
HH: I have restore the stack download section, however - thanks again 
for your reminder that it can be useful).

I've experimented with the securityPermissions as a possible solution 
for this (yep, 4W SecureRunner is in RevNet's now-restored Stack Files 
section), but as wonderful as that is for stacks designed to work within 
certain restrictions it breaks anything that expects to have file I/O, 
inter-process abilities, or any other securityPermissions you've turned 
off to test a stack.

It would be ideal if we had a sort of runtime Docker-like way to create 
virtual containers for script execution, where we could virtualize 
things that securityPermissions may disallow in a way that would allow 
the host LiveCode environment to handle as we see fit.  For example, if 
a script wants to read a file we could see which file it wants and allow 
reads from some folders but not others.

I can't imagine anyone having time for something like that, though.

Going the other direction, we could allow unbridled execution of 
downloaded stacks if we can trust the source.  But that would require 
some form of stack signing, which seems as complicated to implement as 
it would be expensive to maintain (imagine the folks at LC Ltd taking on 
the role of Verisign for stack files).


Separate from the question of security is a larger one:

Is a stack repository even something we need/want the core dev team to 
be tasked with maintaining?

R's CRAN, Python's PyPI, Perls CPAN, and others are all maintained by 
the communities of those languages, leaving the core dev teams to keep 
their focus on the scripting engines they produce.

After all, a stack repository is for the community and comprised of 
files made by the community, and maintaining a set of stack files and a 
UI for accessing them is fully within the technical abilities of our 
community.


If it were seen as desirable for the community to take this on, I see at 
least one way it could happen safely without an expensive engine or 
format change, but before we go too far down that road it seems saner to 
first find out what the intentions are with this removal of the UI to 
access RevOnline.

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





More information about the Use-livecode mailing list