Offline photo sync with kinedb

The phone saves a photo and its record in an embedded kinedb database, with no network. The sync sends the photo as chunks named by their hash. The link between the phone and the server is a proxy that you control: slow it down, cut it, or lose a reply.

Loading…

Phone

Waiting to be sent

—

Photos on the phone

Log

Link (proxy)

Offline Speed: full 3G (384 kbit/s) GSM (40 kbit/s)

Scenario 1 — the connection drops halfway

Save a photo of 1 MB or more.
Sync now. The sync fails. The server holds no row of the photo, only some of its blocks (right side).
Sync again. Only the missing chunks go: see "chunks sent now".

Scenario 2 — the server commits, the phone misses the reply

Save a photo.
Sync now. The sync fails. The server holds the photo, once.
Sync again. The server answers "replayed". 0 chunks go, and the count stays at 1.

What passed the link

0chunks

0chunk bytes

0pushes

0drops

0replies lost

Frames

Server — db.kinedb.com

The selected photo:

—

–

copies of the photo

–

copies of the record

0 = not on the server yet · 1 = on the server, once · 2 or more would be a duplicate. A phone that sends again must not make a second copy.

Every photo of this phone

No photo yet.

The last sync

No sync yet.

Known limits of this PoC (kinedb gaps, not solved here):

The phone database lives in memory. A reload loses what was not synced; the sync then brings the records back from the server. Durable browser storage (OPFS) is kinedb B1215.
The photo and its record are two local commits. One commit for both on a synced table is kinedb B1423. The sync sends the photo first, so the server never holds a record without its photo.
The sync brings the records down, but not the photo bytes (kinedb B1425). A photo marked "image from the server" is the server's copy, not a copy on the phone.
The engine holds a whole photo in memory. Very large files are kinedb B1429.
This is the browser runtime (WebAssembly). Native iOS and a Swift interface do not exist yet.