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