4 ms·

I agree with the sentiment, but for entirely different reasons. An offline capable application that sometimes tries to sync can be called "Online with Extreme

I agree with the sentiment, but for entirely different reasons. An offline capable application that sometimes tries to sync can be called "Online with Extreme Latency", but that is not what true ~~Scotsman~~ offline is. Offline/online is first and foremost about data locality and data ownership. In an online application (regardless of latency!) the source of truth is "the server". Offline application itself is the source of truth and "the server" is a slave. The OP seems to be talking about thin vs fat clients. Fat client is still a client - it fetches data. Offline application is the data source for "the server", it's the server that has to adapt to local changes not the other way around. Naturally, this is problematic since now you have multiple sources of truth. However, shifting source of truth to "the server" does create online application with extreme latency - fat client.

inferense 4y ago
> Offline/online is first and foremost about data locality and data ownership. not necessarily if the data is stored in a proprietary format.
- Sakos 4y ago
  It doesn't matter if it's a proprietary format. Proprietary formats can be reverse engineered and modified and converted. There is a world of difference between a proprietary file that I have online in a form that I can't access directly (and I have no idea how it's being accessed, changed or stored by the service itself or third parties) and a file that I have on my harddrive that I have complete control over.
- deleted 4y ago
  [deleted]
- tnel77 4y ago
  Yes, but I think most people care about availability of data over true ownership of data. If I’m running a business and my internet goes out, there’s a huge selling point to a local DB that allows my operations to keep chugging along until Comcast figures out their mess. Internet returns, my DB syncs with a server offsite, and now I have that backup.
kdmccormick 4y ago
Isn't that more like "decentralized vs centralized" though? In my experience talking with coworkers about online vs offline apps, the article's definition is what we use. Granted, I've worked exclusively in Web dev for years so maybe it's all contextual.
- JohnFen 4y ago
  I don't view things like the article states, and I likely won't for a number of reasons other commenters have stated, plus one more: If offline is online with with extreme latency, then "extreme latency" must include "infinitely long latency". But accommodating infinitely long latency requires a different approach than if you assume that a server will be contacted at some point.
- friendzis 4y ago
  Yes and no, IMO. While these are different classifications, some concepts can be cross applied. Decentralized essentially means absence of built-in omniscient entity - each end every connection is treated as one between equally correct peers. It does not mean that a pair of entities cannot establish hierarchy, it simply means they do not have to. Take git for example. There is nothing forcing us to treat github/gitlab/etc as the omniscient node even if it is central point of data exchange - you are free to disagree with the upstream changes. Local data is always there, all local overwrites are explicit and so on. Contrast this with something like online game. The server will tell the client what their state is - there is a central entity controlling the truth. Web can be interesting in this context, since there are multiple "tiers" of nodes: user applications, backend servers, databases. Data control and conflict resolution properties usually are different among nodes in the same tier and between tiers.
jchanimal 4y ago
I think I agree with the analysis. It's why aspects like data verifiability are potentially more important than fancy peer-to-peer routing and transfer protocols. Once you have Merkle proofs of data, it's just as powerful whether it is on the client or server. Cryptographic verifiability make data locality into an optimization problem not a trust problem: https://fireproof.storage/documentation/how-the-database-engine-works/ https://fireproof.storage/documentation/how-the-database-eng...
- Karrot_Kream 4y ago
  Trust and anti-corruption are just two of many properties you need for data locality, arguably less important. Conflict resolution or consensus is still very, very difficult. P2P routing and transfer is a bit of a red herring. You still need consensus between your local store and the remote store. Fireproof does it using IPFS underneath which in my experience tends to be quite slow, but is a working solution.
Scubabear68 4y ago
A good example of this is are mobile applications used in logistics for tracking movements within a terminal. Often the wifi environment is terrible and the operators will spend significant time not connected. They often have fat clients with local storage, and when the reconnect the sync bidirectionally - they upload whatever they have done since last connection, and they download changes others have made that may affect them in the meantime.
foobazgt 4y ago
I believe thinking about it as "offline vs online" obscures what's actually difficult about offline operation. It's not storage or ownership of data that's difficult, it's conflict resolution. The longer you're disconnected, the more things diverge, the better your merging/resolution schemes/algorithms need to be. There are a lot of ways of thinking about and approaching the problem, some of which work worse or better under different circumstances. You see it in distributed consensus, multi-master systems, version control systems, etc. There's ongoing work in the form of things like operational transforms and CRDTs, but clearly their needs to be a lot more progress in the area.
forgotmypw17 4y ago
A lot of it is also about accessibility to someone with limited network access. When you are developing with an always-on connection and a high-performing device, it's easy to ignore all the scenarios where someone doesn't have either one.
- dopidopHN 4y ago
  There is tool to mimic that : the venerable “Charles” proxy for instance. But I think it’s part of webTooling in the browser
hinkley 4y ago
An app I was designing about six years back would have been something that some would use in their yard and others would use in a national park. In the yard you have extreme latency. Sooner or later you'll get thirsty and you'll walk into WiFi distance. In a national park there's no connectivity. You won't be able to get or receive anything until long after the moment has passed. None of the answers you get will be relevant anymore for most people (what percent of people who visit a national park visit the same one over and over again?). Then I realized screen contrast wasn't 'there' yet so I shelved it, got busy, and there it remains collecting dust.

inferense 4y ago

> Offline/online is first and foremost about data locality and data ownership. not necessarily if the data is stored in a proprietary format.

Sakos 4y ago
It doesn't matter if it's a proprietary format. Proprietary formats can be reverse engineered and modified and converted. There is a world of difference between a proprietary file that I have online in a form that I can't access directly (and I have no idea how it's being accessed, changed or stored by the service itself or third parties) and a file that I have on my harddrive that I have complete control over.
deleted 4y ago
[deleted]
tnel77 4y ago
Yes, but I think most people care about availability of data over true ownership of data. If I’m running a business and my internet goes out, there’s a huge selling point to a local DB that allows my operations to keep chugging along until Comcast figures out their mess. Internet returns, my DB syncs with a server offsite, and now I have that backup.

kdmccormick 4y ago

Isn't that more like "decentralized vs centralized" though? In my experience talking with coworkers about online vs offline apps, the article's definition is what we use. Granted, I've worked exclusively in Web dev for years so maybe it's all contextual.

JohnFen 4y ago
I don't view things like the article states, and I likely won't for a number of reasons other commenters have stated, plus one more: If offline is online with with extreme latency, then "extreme latency" must include "infinitely long latency". But accommodating infinitely long latency requires a different approach than if you assume that a server will be contacted at some point.
friendzis 4y ago
Yes and no, IMO. While these are different classifications, some concepts can be cross applied. Decentralized essentially means absence of built-in omniscient entity - each end every connection is treated as one between equally correct peers. It does not mean that a pair of entities cannot establish hierarchy, it simply means they do not have to. Take git for example. There is nothing forcing us to treat github/gitlab/etc as the omniscient node even if it is central point of data exchange - you are free to disagree with the upstream changes. Local data is always there, all local overwrites are explicit and so on. Contrast this with something like online game. The server will tell the client what their state is - there is a central entity controlling the truth. Web can be interesting in this context, since there are multiple "tiers" of nodes: user applications, backend servers, databases. Data control and conflict resolution properties usually are different among nodes in the same tier and between tiers.

jchanimal 4y ago

I think I agree with the analysis. It's why aspects like data verifiability are potentially more important than fancy peer-to-peer routing and transfer protocols. Once you have Merkle proofs of data, it's just as powerful whether it is on the client or server. Cryptographic verifiability make data locality into an optimization problem not a trust problem: https://fireproof.storage/documentation/how-the-database-engine-works/ https://fireproof.storage/documentation/how-the-database-eng...

Karrot_Kream 4y ago
Trust and anti-corruption are just two of many properties you need for data locality, arguably less important. Conflict resolution or consensus is still very, very difficult. P2P routing and transfer is a bit of a red herring. You still need consensus between your local store and the remote store. Fireproof does it using IPFS underneath which in my experience tends to be quite slow, but is a working solution.

Scubabear68 4y ago

A good example of this is are mobile applications used in logistics for tracking movements within a terminal. Often the wifi environment is terrible and the operators will spend significant time not connected. They often have fat clients with local storage, and when the reconnect the sync bidirectionally - they upload whatever they have done since last connection, and they download changes others have made that may affect them in the meantime.

foobazgt 4y ago

I believe thinking about it as "offline vs online" obscures what's actually difficult about offline operation. It's not storage or ownership of data that's difficult, it's conflict resolution. The longer you're disconnected, the more things diverge, the better your merging/resolution schemes/algorithms need to be. There are a lot of ways of thinking about and approaching the problem, some of which work worse or better under different circumstances. You see it in distributed consensus, multi-master systems, version control systems, etc. There's ongoing work in the form of things like operational transforms and CRDTs, but clearly their needs to be a lot more progress in the area.

forgotmypw17 4y ago

A lot of it is also about accessibility to someone with limited network access. When you are developing with an always-on connection and a high-performing device, it's easy to ignore all the scenarios where someone doesn't have either one.

dopidopHN 4y ago
There is tool to mimic that : the venerable “Charles” proxy for instance. But I think it’s part of webTooling in the browser

hinkley 4y ago

An app I was designing about six years back would have been something that some would use in their yard and others would use in a national park. In the yard you have extreme latency. Sooner or later you'll get thirsty and you'll walk into WiFi distance. In a national park there's no connectivity. You won't be able to get or receive anything until long after the moment has passed. None of the answers you get will be relevant anymore for most people (what percent of people who visit a national park visit the same one over and over again?). Then I realized screen contrast wasn't 'there' yet so I shelved it, got busy, and there it remains collecting dust.