> I still think engineering for slow internet is really important, and massively under appreciated by most software developers, but ... LEO systems (like Starlink, especially StarLink) essentially solve the core problems now.
I don't think that this is a valid assessment of the underlying problem.
Slow internet means many things, and one of them is connection problems. In connection-oriented protocols like TCP this means slowness induced by drop of packets, and in fire-and-forget protocols like UDP this means your messages don't get through. This means that slowness might take multiple forms, such as low data rates or moments of high throughput followed by momentary connection drops.
One solid approach to deal with slow networks is supporting offline mode, where all data pushes and pulls are designed as transactions that take place asynchronously, and data pushes are cached locally to be retried whenever possible. This brings additional requirements such as systems having to support versioning and conflict resolution.
Naturally, these requirements permeate onto additional UI requirements, such as support for manually synching/refreshing, displaying network status, toggling actions that are meaningless when the network is down, rely on eager loading to remain usable while offline, etc.
> I don't think that this is a valid assessment of the underlying problem.
Inmarsat is an insecure, 2 Mbps (at best) connection with satellites at 22236 miles above Earth and a latency of about 900-1100 ms.
Starlink is a secure, 100 Mpbs (typical) connection with satellites at 342 miles above Earth and a latency of about 25 ms.
Odds of getting a video link on Inmarsat are low, and even if you do, it's potato quality. Source - have been using these systems operationally since the 1990s.
Delay/disruption tolerant networking (DTN) seeks to address these kind of problems, using alternative techniques and protocols: store-and-forward, Bundle protocols and Licklider Transmission Protocol. Interesting stuff, enjoy!
I don't think that this is a valid assessment of the underlying problem.
Slow internet means many things, and one of them is connection problems. In connection-oriented protocols like TCP this means slowness induced by drop of packets, and in fire-and-forget protocols like UDP this means your messages don't get through. This means that slowness might take multiple forms, such as low data rates or moments of high throughput followed by momentary connection drops.
One solid approach to deal with slow networks is supporting offline mode, where all data pushes and pulls are designed as transactions that take place asynchronously, and data pushes are cached locally to be retried whenever possible. This brings additional requirements such as systems having to support versioning and conflict resolution.
Naturally, these requirements permeate onto additional UI requirements, such as support for manually synching/refreshing, displaying network status, toggling actions that are meaningless when the network is down, rely on eager loading to remain usable while offline, etc.