New(?) Idea for Standalones

[Richard Gaskin]

Alex Tweedly wrote:

 > On 27/03/2021 00:35, Richard Gaskin via use-livecode wrote:
 >>
 >> What are you looking for?  When were these "good ol days" in which
 >> one could run stack files without an engine, and how did that work?
 >>
 > I can describe what I would like; that may be similar to what Roger is
 > looking for. Or it may not.
 > But I think it is :-)
 >
 > I'd like to be able to develop a stack and give it to a friends or
 > family, and have them run it on their iOS or Android devices. I don't
 > want to get involved in building iOS standalones (or even installing
 > xCode), so ideally I would give them a simple app (i.e. stackRunner
 > kind of thing), and then my "app" as a document to load into that
 > 'runner' app.
 >
 >> There are many reasons it would be problematic to make one generic
 >> "player" for everyone's stack files, mostly user experience but also
 >> app store restrictions, and additional technical requirements for any
 >> devs using it to keep stacks playing nicely together.
 >
 > I'm not going to sell apps, or distribute them widely, so I (don't
 > think  I) care about app store restrictions.

None of us would, because Apple's app store explicitly prohibits apps 
that act anything like app stores, so any distribution would be outside 
of their app store.


 > I also don't care about 'user experience' in the sense of branding or
 > feeling like a unique app.

If I were delivering a standalone that ran stacks as courses for 
elementary students, I'd design it differently than if the standalone 
were aimed at adult learners, or at organizations where the stacks could 
be collaboration or productivity tools.

Everything, even with the most trivial products, comes down to: What are 
you making and who's it for?

A one-size-fits-all really fits none, with either clothes or software.

This is something that's been part of my career since the mid-90s, when 
I was working on this very question with the folks at Allegiant 
Technologies for SuperCard. Much of the work I've done all these years 
is building authoring systems for people to deliver interactive 
experiences.  I've had lots of time across a dozen industries to think 
this through.

A generic player is one of those things that seems simple, but is only 
simple in practice to the degree that it doesn't deliver a great experience.



Let's set design aside for the moment and look at one other corner of 
this: licensing.

A generic player poses a potential risk to proprietary editions of LC, 
since it could be used as a way for folks to bypass a need for licensed 
standalone building.  Understandably, the LC EULA for the proprietary 
editions prohibit building a generic player.

However, the GPL serves an entirely different set of goals, emphasizing 
the freedom for the recipient of a work to do whatever they want with it 
all the way down to the source code.

This makes the Community Edition a natural fit for a generic player, 
since the proliferation the license explicitly encourages would be very 
much with the grain of its goals.

But then we have to ask: how many of those who might enjoy a generic 
player embrace the GPL with the stacks they'd like to distribute it with?

If there's enough people into the GPL that part of the licensing 
questions is solved.  But at the moment I'm not sure that's the case, 
and even if it is we're still left with the other question of 
security/liability:


If I make a standalone that runs stacks designed for a specific range of 
needs under my supervision, I have no problem putting my name on it 
since it's all code I can vet.

But if I make a generic player and someone else decides to distribute 
malware for it, LC is quite powerful, and quite powerful damage could 
result, rapidly, to the lives of everyone who ran it.

Of course, depending on the jurisdiction, chances are good I'd prevail 
if someone tried to assert that my company's reputation is what 
encouraged them to believe that any stacks run with it would be at least 
reasonably safe, despite whatever disclaimer I'd included (case law is 
mixed on this).

But can you imagine the time and money needed to defend a case like that?

It only takes one annoyed person with deep pockets to turn your life 
into a living hell, even if you eventually "win" the case.



 > I'm not sure what you mean by  "additional technical requirements..."
 >
 > If that's feasible, I'd happily buy (or contribute cost towards) such
 > a 'runner' app. I doubt that I'd be the only one.

The technical side of this would be longer than the above, which is 
already too long.  I've found that the more complete my answers here the 
less they're read, so there's a point where mail lists just aren't a 
great place for deep dives.


TL/DR:

If all one wants is a vanilla runtime engine and doesn't care about 
either user experience, licensing, or security, just make a standalone 
with an "Open File..." item in its file menu and you're done.

You still need to get the engine to the user, but that only needs to be 
done once.

Anyone can build that.  Keep it for your own stuff among friends and no 
one will likely mind; or distribute it broadly under GPL with the 
Community Edition and you're good with that too.


Anyone interested in a more serious effort to distribute works within a 
solid design and architecture for a specific segment -- whether 
education, business, or something else -- drop me an email and let's talk.

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