Curry Kenworthy wrote:
> One general problem is that backward-compatibility
> has been abandoned and even politicized/demonized
> by some of the big players. (Hello Mr. Jobs.) BC
> is actually just part of a bigger concept. I don't
> have the correct word for that concept handy
> (Richard?) but when we build upon other frameworks
> (like FB, Google, or LiveCode itself), it helps
> if the APIs and keywords do not change rapidly.
> A sound foundation. That way "middle" code can be
> designed to last. If the big guys wantonly break
> code, it's an incredible waste that the consumer
> (or someone, sometimes us) has to pay.

I don't have any terminology suggestions there; I think you characterized the risks well.

LC is almost unique in its strong support for backward compatibility. Many other systems appear cavalier by comparison in that respect, so much so that it never even occurs to their users that backward compatibility could be something one might ask for.

APIs, though, are in a special class, esp. those related to authentication and authorization. The threat landscape changes almost daily, and good service providers will change their APIs to keep up.

I can't recall if it was from Sean or someone else, but earlier in this thread someone noted that Google provided some two years of advance notice on this particular change, and then went even further to extend the EOL date a couple months further than originally announced.

If an app *must* increase its complexity by introducing dependency on third-party cloud services over which we will have no control, any and all channels for receiving communications from the vendor must be closely monitored (white list dev announce addresses, check the dev blogs periodically, etc.).

For me, the bigger question is that *must*: "Is introducing dependency on an external service over which I have no control truly necessary?"

Sometimes it is, and if so you build for dependency on it and pray.

But if my needs are modest enough that I can handle them myself, I'm inclined to do that.

If all I need is a simple UI for folks to enter data and post a tabular file to a server for my app to pick up, I might be inclined to make that data entry app myself to keep things simple and predictable.

And if the usage scenario is all on one local network, I'd be inclined to use a Raspberry Pi or spare PC as the server right there next to me, rather than adding the unpredictability that comes with the open Internet.

It's kind of amazing we lose so little data on the Internet, but we do from time to time. And living here in Hollywoodland I can appreciate what Sean writes about the pressures involved in studio shoots. If you have a long history in the software biz and haven't spent time on a TV production, it's hard to appreciate how different that work environment is: Scheduling studio time is hard, once you're there you're burning tens of thousands an hour, and it's entertainment so the happy flow of every person on set does matter. In short, the impact of any delay ranges from extremely damaging to the production, to intolerably destructive. Studio time is high-pressure time for techs.

Relying only on the local network eliminates the rare-but-has-indeed-happened risk of DDoS or DNS attacks and other factors that can make a cloud provider unreachable. Remember when Twitter and dozens of other services were knocked offline across the US eastern seaboard for several hours in Oct 2016? The didn't end because the good guys stopped it. It ended only because the bad guys apparently felt they'd made their point and showed mercy. It was a muscle-flexing exercise, a way to let us know they can do it again at any time, and could be sustained for a full day or more if they choose.

With burn rates like studio production, unless the open Internet is needed I'd be *very* inclined to move any server the system is dependent on to the local net.

And even if the wild west of the open Internet is truly required, unless I need the specific features of a third-party service I'd consider rolling my own. Data entry apps to produce tabular data are cheap and fun to make in LC, and bring a hundred unknowables under your own control.

 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