Was: URGENT: MergGoogle no longer works on iOS: CLIENTS VERY UNHAPPY
ambassador at fourthworld.com
Sat May 26 12:40:49 EDT 2018
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.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the Use-livecode