Was: URGENT: MergGoogle no longer works on iOS: CLIENTS VERY UNHAPPY

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com