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
____________________________________________________________________
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
