4 ms·

They don't want to send down the entire message history every time you switch to a particular conversation window, they want to be able to store as much of that

by phpnode 10y ago

They don't want to send down the entire message history every time you switch to a particular conversation window, they want to be able to store as much of that locally as is possible/sensible so that the user doesn't have to wait for a network round trip and it still mostly works offline. They would like to store these messages in IndexedDB but they would like to encrypt them first.

paulddraper 10y ago
Browsers have had HTTP caches for decades. But yeah, IndexedDB is nice too.
- Klathmon 10y ago
  HTTP caches are great for their intended use case, but when used like this they have a lot of limitations. You can't rely on them existing, having space, or keeping your data for any real amount of time. You can't process the data before it hits the cache, you can't clear them easily, and they are iffy at best when offline.
  - paulddraper 10y ago
    > You can't rely on them existing, having space, or keeping your data for any real amount of time In other words, a cache.
    - Klathmon 10y ago
      Yes, but a cache with zero reliability isn't very useful. If I do an expensive operation, then need to use its result later, I can't rely on the HTTP cache as the browser may never have cached it in the first place, or may have evicted it by the time I go to use it. So using that unreliable cache can actually make things worse in the sense of more data usage, more power usage, more battery usage, and more memory usage. For a real world example, say I wanted to pre-fetch a bunch of data on page-load, then in a later page I want to use the cache to be able to quickly get that information and use it without any latency. If I had some control over the HTTP cache, I could do this. But as it stands right now, I can try to make a GET request on the page load, but when the user clicks the button to see the result on a later page, it's a crapshoot on whether or not the HTTP cache will still have it, leading to the user having to wait sometimes, and not other times, duplicated requests, and a lot more data usage. With localstorage, IndexedDB, WebSQL, etc... I have that control. I can know that the information is going to stay there until I need it so I don't need to worry about my caching making things worse.
- phpnode 10y ago
  This is a chat application, the primary transport is WebSockets, not HTTP.

by phpnode 10y ago

paulddraper 10y ago

Browsers have had HTTP caches for decades. But yeah, IndexedDB is nice too.

Klathmon 10y ago
HTTP caches are great for their intended use case, but when used like this they have a lot of limitations. You can't rely on them existing, having space, or keeping your data for any real amount of time. You can't process the data before it hits the cache, you can't clear them easily, and they are iffy at best when offline.
- paulddraper 10y ago
  > You can't rely on them existing, having space, or keeping your data for any real amount of time In other words, a cache.
  - Klathmon 10y ago
    Yes, but a cache with zero reliability isn't very useful. If I do an expensive operation, then need to use its result later, I can't rely on the HTTP cache as the browser may never have cached it in the first place, or may have evicted it by the time I go to use it. So using that unreliable cache can actually make things worse in the sense of more data usage, more power usage, more battery usage, and more memory usage. For a real world example, say I wanted to pre-fetch a bunch of data on page-load, then in a later page I want to use the cache to be able to quickly get that information and use it without any latency. If I had some control over the HTTP cache, I could do this. But as it stands right now, I can try to make a GET request on the page load, but when the user clicks the button to see the result on a later page, it's a crapshoot on whether or not the HTTP cache will still have it, leading to the user having to wait sometimes, and not other times, duplicated requests, and a lot more data usage. With localstorage, IndexedDB, WebSQL, etc... I have that control. I can know that the information is going to stay there until I need it so I don't need to worry about my caching making things worse.
phpnode 10y ago
This is a chat application, the primary transport is WebSockets, not HTTP.