#indexeddb

Une librairie pour simplifier l’utilisation en javascript des différents types de « stockage local » des navigateurs.
GitHub : ▻https://github.com/localForage/localForage

#offline #javascript #localStorage #IndexedDB #WebSQL #localForage

Concernant la lecture hors-ligne, qui me semble le seul (?) avantage potentiel d’une appli native sur la version web, il y a des choses possible désormais en javascript dans le navigateur, qui peut servir de cache et de base de donnée pour un site web mobile lisible hors-ligne,[edit] avec notifications web, et tâche de fond. Voir #pwa par exemple, et #local_storage et #IndexedDB

Cela me semblerait intéressant de creuser cela pour SPIP dans son ensemble.

Les notifications aussi sont un avantage, la mise à jour en tache de fond....

Les notifications et tâches de fond on l’air possibles également.

►https://developers.google.com/web/progressive-web-apps

Push Notifications
Web push notifications makes it easy to re-engage with users by showing relevant, timely, and contextual notifications, even when the browser is closed.

▻https://w3c.github.io/ServiceWorker/spec/service_worker/index.html

This specification describes a method that enables applications to take advantage of persistent background processing, including hooks to enable bootstrapping of web applications while offline.

The core of this system is an event-driven Web Worker, which responds to events dispatched from documents and other sources. A system for managing installation, versions, and upgrades is provided.

The service worker is a generic entry point for event-driven background processing in the Web Platform that is extensible by other specifications.

Si les magiciens de seenthis arrivaient à avoir une lecture hors-ligne, ça serait tellement utile !!!!!!

Le service qui serait LE truc utile pour moi serait de s’intégrer au système de partage sur Android, de manière à ce que, quand je lis un article cool, je puisse le partager sur SeenThis aussi facilement que via Twitter, courrier, SMS, etc.

Architecture

osm-p2p implements a kappa architecture where all updates are written to an append-only log. This log is the “source of truth” that populates indexes called materialized views. These materialized views are only meant to answer questions faster than reading the whole log. If the views need to change in the future to accommodate different queries, they can be regenerated from the log without having the migrate the log schema.

Each update is written to an append-only log provided by hyperlog, a module from the dat project. This log has indexes which provide different materialized views of the data.

One view (hyperkv) provides a key/value interface mapping OSM ids to documents. Another view creates a spatial index to answer bounding box queries (hyperlog-kdb-index).

During replication, each side requests the documents from the log that it doesn’t have and appends those documents to its own log. The indexes watch these inserts and buffer requests until the they are caught up with the latest known document in the log.

cc @louca @shenriod

#local_storage #IndexedDB

#local_storage #IndexedDB

#local_storage