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.


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

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

Reply via email to